How to migrate data from a legacy OA

Do not lift-and-shift the whole database. Split in-flight tickets, historical archive, and master-data mapping. Hang the old library read-only, trial, then cut over—so go-live day is not “we cannot find the ticket.”

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.

Sorting legacy files against a new management back office

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.

Cutover week · trial, then close the old entry

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.

Master data before tickets

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.

List in-flight tickets and must-search history before you talk migration

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.

Contact Us

Email
service@wehoope.com
Phone
+86 139-2520-6166
Address
W903, Shenzhen-Hong Kong Industry-University-Research Base, No. 201 Gaoxin South 7th Road, High-tech Zone Community, Yuehai Subdistrict, Nanshan District, Shenzhen