In a system migration, customer records, orders and financial data almost always make it to the new system. What gets lost is whatever nobody listed: a rule the old system applied on its own, an email alert it sent, a report someone opened every Monday. This article covers what to inventory, clean and test before cutover so none of that disappears without you noticing.
What gets lost in a system migration is almost never the data
Copied data is easy to verify: count the rows on both sides. What disappears is behavior. The discount the system applied to certain customers without anyone asking. The permission that kept salespeople from seeing product cost. The alert that warned the warehouse when an item dropped below its minimum.
Nobody asks the new system for these things because nobody remembers the old one did them. Two weeks after cutover, the first invoice goes out without the discount agreed with a long-standing customer. The record is there. The rule stayed behind.
Start with an inventory of what the current system does
Before copying any file, list what the current system does in four groups: data (records, history, attachments), automatic rules (calculations, approvals, blocks), connections to other systems (store, bank, invoicing) and outputs (reports, emails, documents).
To fill in the list, ask people, not the system. Each department answers one simple question: what do you open every day, every week and at every month end? The people who use the system know functions no manual records.
Each item on the list gets a destination: migrates as is, gets rebuilt differently in the new system, or gets dropped on purpose. Dropping something is a valid decision. Leaving it out without deciding is what turns into a problem later.
Clean up before you migrate, not after
Migrating messy records means paying twice: once to carry the mess over, and again to clean it up inside the new system, where it has already polluted reports and integrations. A common example is the same customer entered three times, with the tax ID typed three different ways. After migration, that customer's history sits in three pieces.
Before the copy, resolve duplicates, close records that have sat idle for years and delete entries linked to nothing. Then decide how much history moves to the new system: all of it, or only what is active, with the rest kept in a searchable archive.
This is a business decision, not a technical one. Ask finance and your accountant how long you need to look up each type of record, and migrate what those answers require.
How to run a system migration without stopping the business
First, a rehearsal. Migrate a copy of the data into the new system and have the people who use it check cases they know by heart: an old customer, a complicated order, a past month-end close. A sample check by someone who knows the case finds errors that a row count misses.
Then, a period in parallel. Both systems run together until one full business cycle (a month-end close, for example) is done and the numbers match. It means double the work for a while. That is the price of finding the error before your customer finds it for you.
At cutover, pick a low-traffic day and leave the old system intact, read-only, for a while. If something essential is missing from the new one, there is a way back and nothing is lost.
Before you set the cutover date
Before fixing the date, answer five questions. Does every automatic rule in the old system have a defined destination? Has every connection to another system been tested with real data? Has someone from each department checked cases they know? Did the new system's numbers match the old one's across a complete close? Is there a way back if something fails in the first week?
If any answer is "I don't know", that is the next task, not a detail for after cutover.
YM does this inventory before any migration: it lists what your current system does, what must move to the new one and what can stay behind. Reach us on WhatsApp (+55 92 8129-8199) or by email at contato@ygormendanha.com.