Move your practice data
with confidence

A single, named individual within the firm must own the migration on the client side. This is not a role to delegate to a junior staff member or someone already at full capacity.

Your internal project owner must have:

• Decision-making authority — they can approve data mapping decisions and sign off on trial migration results without escalating every issue
• Consistent availability throughout the project, not sporadic engagement
• Working knowledge of your existing PMS and its data structures
• Internal influence to protect migration time when client work competes for capacity

The discovery phase exists to map your source system before migration scripting begins. Skipping or rushing this phase creates rework that cascades through every subsequent phase.

• Provide full access to the source system database in a timely manner
• Make available a technically qualified internal resource who understands your source system's data structure
• Be honest about data quality issues — incomplete records, inconsistent entry practices, legacy data that was never cleaned up
• Respond to discovery questions from the migration team within 24–48 hours
• Review and sign off on the agreed scope document before migration work commences

Before each migration phase — and critically before go-live — your accounts team must run a defined set of financial reports. These are the baseline for validation and cannot be rushed or approximated.

• All matter balances and client balances
• Trust account balances — to the penny
• Work in progress totals
• Invoice and disbursement ledgers
• Client and matter counts

Reports must be run at a specific point in time, with all users locked out of the system, so that the data is static. If transactions continue to be posted after the report run, the baseline is invalidated.

Trial Migration 1 is an invitation for your team to review what has been migrated and identify discrepancies. The migration team will have made assumptions about data mapping — some may be incorrect. TM1 is the mechanism for finding and correcting these before they compound.

• Assign staff with financial and operational knowledge to review — not just a technical resource
• Compare migrated data against scoping-phase reports, line by line where necessary
• Document discrepancies clearly and specifically — "trust account balance is $X in source and $Y in Yao" is actionable; "the data doesn't look right" is not
• Submit feedback within the agreed review window (typically one to two weeks)
• Understand that feedback received after the window closes may not be incorporated until Trial Migration 2

The go-live date is agreed at project kickoff and represents a reserved capacity slot. When you accept a slot:

• That slot cannot be reallocated to another client
• Yao Technology has planned resource and team availability around that date
• Your subscription costs will commence from the agreed go-live date

If internal readiness slips — staff availability, unresolved data queries, incomplete validation — and you miss your slot, the next available slot is determined by the migration calendar, not your preferred timeline.

• Friday afternoon: Lock all users out of the source system. No further transactions to be posted from this point
• Friday evening: Accounts team runs the full set of agreed financial reports and provides them to the migration team — these are the definitive baseline
• Friday evening: Database backup is taken (by the client or by Yao Technology, as agreed)
• Saturday–Sunday: Migration team executes. Your accounts team must be available to answer data queries as they arise
• Monday morning: All users ready to log in to Yao Mind. Any issues must be escalated immediately through the agreed channel

Hypercare is the period immediately after go-live when the full user base returns to the system. During this window:

• A designated client contact must be available and responsive throughout the working day
• Triage and report issues immediately — do not accumulate a list
• Distinguish between a critical blocking issue (all users cannot work) and a cosmetic issue (a report looks different) — critical issues take absolute priority
• Do not allow staff to revert to old system workarounds — raise issues through the project channel first

After hypercare, the project transitions to standard support. The migration team's intensive involvement ends at this point.