What Is a System Migration?
A system migration means moving a business from one system to another: its data, processes, integrations and people. Examples include moving from one CRM to another, from a spreadsheet-based process to proper software, or from an ageing in-house system to a modern platform.
Businesses usually migrate because they’ve grown, the old system has become hard to maintain or is no longer supported, or a new platform can do things the old one can’t.
It’s rarely just a case of moving data from one database to another. A CRM might feed finance software, a customer portal and marketing tools. An ERP might sit at the centre of purchasing, stock and fulfilment. Move one system and the effects spread across the business.
What Should You Check Before Migrating?
Start by documenting how the current system is actually used, not how it was meant to be used. Ask:
- What data does the system hold?
- Which business processes depend on it?
- Which other systems connect to it?
- Where does information enter and leave it?
- Are there spreadsheets or manual steps propping it up?
- Which parts are critical to the day-to-day running of the business?
This matters most with older systems. Over the years, teams build workarounds that nobody writes down: a spreadsheet here, a manual export there. Miss them, and the new system goes live without something the business relied on.
A process & systems review maps this out. It can also show whether you need to migrate at all, because sometimes the existing system just needs setting up properly.
How Do You Migrate Data to a New System?
Decide what needs to move, map the old structure to the new one, clean the data, then do a trial run before the real thing.
The old and new systems rarely store data the same way. Fields have different names, formats change, and older records often contain duplicates or gaps.
You don’t have to move everything. Sort the data into three groups:
- Move: what the business uses now, such as live customers, open orders and current stock
- Archive: history you need for reference or legal reasons. UK limited companies generally have to keep financial records for six years1, for example
- Leave behind: duplicates, test data and records nobody uses
Then do at least one trial migration into a test copy of the new system. That’s where mapping problems show up, while they’re still cheap to fix. The same applies whether you’re moving to Salesforce, SAP or something smaller: understand the data before you move it.
What Happens to Your Integrations?
They need to be part of the plan from the start, not dealt with afterwards. List every connection the old system has, such as accounting, ecommerce, customer portals, internal apps and third-party services. For each one, decide whether it will be rebuilt, replaced by a ready-made connector in the new system, or no longer needed.
An ERP migration, for example, can affect stock, purchasing, finance and fulfilment at the same time. Changing the central system without understanding those connections causes failures elsewhere.
Where the new system has no ready-made connector for a tool you rely on, a custom integration can link the two.
If you’re also moving from your own servers to the cloud, such as AWS or Azure, include that in the same plan. It’s often safer to do it as a separate step, so fewer things change at once.
How Should You Test a New System Before Switching Over?
Test the business, not just the data. Check that the key workflows, integrations, permissions and reports work, using realistic examples. Then check the data matches between the old and new systems: record counts, totals and a sample of individual records.
Ask the people who use the system every day to run through their own tasks before go-live. They’ll spot problems a project team won’t.
Finding a problem after the old system has been switched off is far more disruptive than finding it in testing.
Should You Switch Over All at Once or in Stages?
It depends on how critical the system is and how much disruption the business can absorb. There are three common approaches:
- Big bang cutover: everything moves at once, usually over a weekend or quiet period. Quickest and cheapest, but if something goes wrong, it affects everything.
- Phased migration: one team, site or function moves at a time. Slower, but problems stay small. The same step-by-step thinking applies when modernising a large platform without a risky full rewrite, as in this legacy platform modernisation project.
- Parallel running: the old and new systems run side by side and the results are compared. The safest option, but staff enter everything twice, so keep it short.
Whichever you choose, plan:
- When the final data transfer happens
- How long the system will be unavailable
- How new information is handled during the switch
- What happens if you need to roll back
- How staff and customers will be supported
Is Migration a Chance to Improve How You Work?
Yes, and missing it is one of the most common mistakes. Recreating the old system somewhere new copies its problems too.
Before you rebuild each process, ask whether it should exist at all. If staff use a spreadsheet because the old system couldn’t handle a workflow, should the new system handle it instead? If two systems hold the same customer information, should they still? If an integration only exists because of an old limitation, is it still needed?
Done well, a migration leaves the business with simpler processes and cleaner data, not just newer software. And if your current system is old and hard to change rather than outgrown, modernising it may be an alternative to migrating at all.
Sources
1 GOV.UK, Running a limited company: your responsibilities, “How long to keep records”
