Week 1 · Inventory
List tickets still in flight, history that must stay searchable, and attachments that can stay read-only. In-flight first; a closed expense from three years ago does not need the new tables.
Failed migrations usually lose on “dump all history into the new tables.” Fields mismatch, attachments drop, approvers have left, and day one is dirty. You are not moving a database file. You are moving the layer that can still be searched, continued, and audited.
List tickets still in flight, history that must stay searchable, and attachments that can stay read-only. In-flight first; a closed expense from three years ago does not need the new tables.
Map org, roles, form fields, and attachment paths one by one. Name-based grants in the old system become role-based; see Why verbal permission rules eventually fail.
Hang history read-only and give the new back office a search door. Audit needs to open the file, not re-run it in the new flow; see What role OA plays in audit and compliance.
Run real in-flight tickets for two weeks. When the dual-run ends, close the old write entry; search can stay. A vanished-vendor swap has a longer list; see Replacing a vendor-abandoned OA: what to watch.
Do not migrate “every draft anyone ever started.” Dirty data in the new library hurts more than an old system that will not open. Prefer a jump to the read-only old library over to-dos assigned to people who no longer match.
If people, departments, and roles are not aligned, tickets will route to departed accounts. If contract numbers and customer names disagree with ops systems, a moved ledger still will not match; see Once contracts live in one ledger, renewals and seals are not tribal knowledge. Extend versus rebuild decides how deep the mapping goes; see Should you extend a legacy OA or rebuild it?.
Attachments are a separate ledger. Legacy OA often dumps scans on a file share and stores only a filename. At migrate time, check that a ticket number still opens the original; log damage instead of pretending success. When a name no longer matches a role, keep history read-only. Do not force an active account to “continue approve” and rewrite responsibility.
DaXi’s default: in-flight tickets enter the new flow; historical attachments stay read-only; master data is rebuilt by role. For an assessment of your old library, go to the Management systems service page and say the vendor and whether you can still export. Cutover belongs on the engineering timeline; see From brief to launch: how a management system is built.
Name the legacy OA vendor, whether you can export, and how many open tickets remain. That is closer to a launchable plan than a whole-database zip.