Data Migration Checklist: Moving to a New Operations Platform

You've picked a new operations platform, the contract is signed, and now someone has to move years of item records, purchase order history, supplier data, and inventory balances out of the old system and into the new one without breaking anything your team depends on daily. This is the part of a platform switch that gets the least attention in the sales process and causes the most damage when it goes wrong.

A data migration checklist for an operations platform move covers four stages: auditing what you actually have before you touch it, mapping and cleaning that data against the new system's structure, validating it during cutover, and reconciling it against live operations for several weeks afterward. Skip any one of those stages and the two you're most likely to skip, the pre-migration audit and the post-go-live reconciliation, are the ones that cause the most expensive failures. The destination matters too. DOSS, the AI-native operations platform for consumer goods, gives item, supplier, and order records one governed structure to land in through Unified Master Data, and brands go live in 4 to 6 months instead of about a year.

The cost of getting this wrong isn't abstract. Migrated data with silent errors doesn't show up as a failure on go-live day; it shows up three weeks later as a purchase order sent to the wrong supplier, a SKU with the wrong reorder point, or a customer invoiced against the wrong price list, and by then nobody remembers which migration step introduced it.

The default approach to data migration is a one-time export and import: pull everything from the old system into a spreadsheet or CSV, hand it to the new platform's implementation team, and let them load it in. This works for genuinely clean data and fails for almost everything else, because it treats migration as a technical transfer problem instead of a data quality problem.

Most operations data accumulated over years of use in a legacy ERP has quiet inconsistencies: duplicate SKU records created because two people set up the same item independently, supplier records with outdated contact and lead time information, unit-of-measure conversions that were fixed manually at the transaction level instead of the master data level. A one-time dump carries every one of those inconsistencies straight into the new system, where they're now baked into a platform your team will run daily operations on for years.

Consultant-led migrations, run as a fixed-scope project separate from your team's day-to-day work, have a different failure mode: they optimize for hitting the go-live date, not for data accuracy your team will discover weeks later. By the time a mismapped field or a truncated field length shows up in a report, the consultants have moved to the next client and the fix falls entirely on your internal team.

The reframe that fixes both failure modes is the same: migration is a data quality project with a technical transfer step at the end, not the other way around.

That means the first work in any migration is auditing your source data before you decide how to map it, not after. Pull a full extract of your item master, supplier records, open purchase orders, and current inventory balances, and look for the patterns that cause the most downstream damage: duplicate records, orphaned records with no active transactions, and fields that are populated inconsistently across your catalog. This audit typically surfaces problems that predate the migration entirely, and fixing them in the old system before you migrate is far cheaper than fixing them in the new one after go-live.

Mapping comes second, and it has to account for structural differences between the old system and the new one, not just a field-by-field copy. A legacy system that stores unit-of-measure conversions as free text needs an explicit mapping decision, not an automatic pass-through, or the new platform will inherit the same inconsistency you were trying to leave behind.

Before any data moves, confirm the following for each core data set: item master, supplier master, open purchase orders, and current inventory balances.

• Duplicate detection: Search for SKUs or suppliers entered more than once under slightly different names or codes, and decide which record is the source of truth before migration, not during it.
• Orphaned records: Identify item or supplier records with no transaction activity in the past twelve to eighteen months, and confirm with the business owner whether they should migrate at all.
• Field completeness: Check that required fields in the new platform, like lead time , reorder point, and unit cost, are actually populated in the source system rather than assumed.
• Unit-of-measure consistency: Confirm that every conversion (cases to eaches, pallets to units) is defined consistently across the catalog, not fixed ad hoc at the transaction level.
• Open transaction cutoff: Set a clear cutoff date for open purchase orders and in-transit inventory, and document how partially received orders will be represented in the new system.
• Partner and integration data: If you work with 3PLs or EDI trading partners, confirm which system will be the source of truth for inventory and order status during the transition, and get that agreement in writing before cutover, not after a shipment goes missing between two systems that both think they own it.

Assign a single owner for each of these checks, someone who can say definitively "this is done" rather than "someone probably looked at it." A checklist with no named owner per item quietly becomes a checklist nobody actually ran.

Cutover is the moment the audited, mapped data actually loads into the new platform, and it needs its own validation step before you treat the new system as the system of record.

Run a reconciliation between the migrated totals and the source system for every core data set: item count, open purchase order value, and inventory quantity by location. A mismatch here is far easier to trace on day one, when the mapping logic is still fresh, than three weeks later when it's buried under a month of new transactions layered on top of a migration error.

Keep the legacy system accessible in read-only mode for at least thirty to sixty days after cutover. Almost every migration surfaces a handful of edge cases that weren't caught in the audit, and having the source data available to check against is the difference between a quick fix and a guessing game about what the original record said.

Spot-check a sample of individual records in addition to the aggregate totals. Totals can reconcile correctly even when individual records are wrong in offsetting ways, so pull twenty or thirty items and suppliers at random and manually confirm every field against the source system before you sign off on cutover.

The checklist doesn't end at go-live. The most common gap in operations platform migrations is treating cutover as the finish line instead of the start of a validation window.

For the first two to four weeks after go-live, reconcile inventory counts, open purchase order status, and supplier lead times against what your team observes in daily operations. A supplier lead time that migrated as thirty days but is actually running forty-five will surface as a real stockout risk before it surfaces as a data correction, so this window is when you catch it before it costs you.

The platform you migrate to determines how much of this discipline is on your team and how much is built in. DOSS is built to make the audit, map, and validate steps easier to execute. More than 100 native integrations cut down the manual export-and-reformat work that introduces errors in the first place. Unified Master Data gives your item, supplier, and location records one governed structure to map into, instead of a field-by-field guess at how the new system's schema should represent your old one. And because DOSS brands typically go live in 4 to 6 months rather than the year a full legacy ERP replacement can take, your validation window against live operations starts sooner, while the people who ran the old system still remember how it worked.

A fast migration doesn't mean skipping the audit and validation steps that make it trustworthy. With DOSS, Forward Deployed Services work alongside your team to get you live in 4 to 6 months, and the checklist above is how you keep that speed from costing you accuracy.

A migration checklist only works if someone owns it end to end: one person accountable for the audit findings, the mapping decisions, the cutover reconciliation, and the weeks of validation that follow. Split across multiple vendors or teams with no single owner, each stage gets treated as someone else's problem, and that's when data quietly breaks.

If your team is staring down a platform switch and the migration plan is still "export everything and hope," that's worth fixing before you sign a go-live date. DOSS puts procurement , inventory management , and order management on one system of record that matches the real world, built on Unified Master Data, so your migrated supplier, item, and order records stay consistent across every module instead of needing separate mapping work for each one. The GL stays where it is, and DOSS posts clean entries to the one you already use. Most brands go live in 4 to 6 months, not years.