How to Choose a Data Migration Partner.
How to choose a data migration partner: three questions separate a supplier who has run one from a supplier who has read about it.
How to Choose a Data Migration Partner.
Key Takeaways
- Three questions separate a supplier who has run a migration from one who has read about it: describe a rollback you performed, what you found in source data nobody mentioned, and how you would phase the cutover.
- Rollback is a selection criterion rather than a contingency. Ask what happens at three in the morning when the cutover has failed and the business opens at eight.
- Migration tooling is mature. Migrations overrun because of what was in the source data.
- Most migration RFPs are too vague to produce comparable proposals, which is how three suppliers end up quoting three different projects.
- The month after go-live is when the problems surface, and it is usually the month the contract stops covering.
Anyone can answer the first two with a story. The tell is in the detail, and the detail is not something you can rehearse. A supplier who has stood over a failed cutover at three in the morning describes it differently from one who has planned for the possibility.
Working out how to choose a data migration partner matters more than picking a method, because the method is largely settled and the execution is not. Our post on data migration strategies covers the approaches themselves, so this one is about selecting the people.
Moving data has more in common with moving house than anyone selling migration software will admit.
Phased Delivery Against Big Bang Cutover
Most buyers want phased delivery and most RFPs fail to ask for it in a way that produces phased proposals.
A big bang cutover moves everything in one window, usually a weekend. It is cheaper when it works, it is simpler to reconcile, and it carries all of its risk in a single evening.
Phased delivery moves a slice at a time, which means running both systems in parallel for a period and keeping them in step. It costs more and it takes longer, and it means no single failure takes down everything at once.
Two cutover shapes, and what each one costs you.
Big bang | Phased | |
|---|---|---|
Duration | One window | Weeks to months |
Cost | Lower | Higher, sometimes much |
Parallel running | None | Required, and it is work |
Failure blast radius | Everything | One slice |
Reconciliation | Once, large | Repeatedly, smaller |
Right when | Low volume, clean data, tolerant business | High volume, messy data, low tolerance for downtime |
If you want phased proposals, the RFP has to say so and has to explain why. Ask each supplier to define the slices, say how they will keep both systems in step during parallel running, and state what they would do if a slice fails after the next one has already started.
That last question is the one that separates real phasing from a big bang with milestones drawn on it.
Rollback is a Selection Criterion, Not a Contingency
The single most useful thing you can ask is what happens at three in the morning when the cutover has failed and the business opens at eight.
A supplier who has done this will answer with specifics. How long the rollback takes, what the decision point is, who makes the call, what happens to transactions that landed in the new system before the failure, and how you verify the old system is genuinely back to a consistent state.
A supplier who has not done it answers with reassurance. They will say they take backups, that it is unlikely, that they have never needed one.
Five rollback questions, and what a real answer contains.
Backups are not a rollback plan. A backup tells you the data exists somewhere. A rollback plan tells you how long it takes to get the business running on it again, and who is authorised to decide.
Insist on a rehearsed rollback rather than a documented one. The difference is roughly the difference between owning a fire extinguisher and having used one.
Data Quality is the Risk, Not the Tooling
Migration tooling is mature. The reason migrations overrun is almost always what was in the source data, and there is good public evidence for that.
The National Audit Office found that government still has a poor appreciation of the state of data in its legacy systems, and that transformation programmes are routinely undermined by it. The same report found more than 20 different ways of identifying individuals and businesses across 10 departments, with no standard format between them.
Sit with that second finding for a moment, because it is the whole problem in one sentence. If the same person exists under twenty identifier schemes, no tool can tell you how many people you have.
What the National Audit Office found in government data, and why it generalises.
The consequences show up in delivery rather than in planning. The NAO reported that a Cabinet Office shared services programme failed to achieve its anticipated savings because of delays migrating customers onto the shared centres, and separately that outdated IT systems and ageing data are a key source of inefficiency across government and a major constraint on transformation.
None of this is unique to the public sector. It is simply the only sector that publishes its post-mortems.
The practical consequence for selection is that any supplier who quotes a fixed price and a date before profiling your data is quoting a number rather than a price. Arch runs a paid discovery stage before committing to an approach, so the data is understood before a cutover date is agreed.
Knowing Whether You Are Migrating or Modernising
Buyers often arrive asking for a migration when the honest answer is that the system underneath needs replacing. The distinction changes who you should be talking to.
The Government Digital Service defines the threshold plainly. Technology becomes legacy when it is end of life, out of support, impossible to update or no longer cost effective, and the service manual sets out principles for moving away from it rather than carrying it forward.
Four tests for whether you are moving data or replacing a system.
Apply those four tests to your source system before you write the RFP. If it fails two or more, a straight migration moves your problem to newer hardware and leaves you to solve it again in three years.
That does not automatically mean a rebuild. It means the RFP should ask suppliers how they would handle the parts that are genuinely end of life, rather than assuming everything transfers as-is.
A supplier who tells you a migration alone will not fix the underlying problem is being useful, even though it makes their proposal look larger than the one next to it. Take that seriously rather than scoring it down.
What to Put in the RFP
Lift this structure directly if it helps. Most migration RFPs are too vague to produce comparable proposals, which is how three suppliers end up quoting three different projects.
Section | What to state | Why it changes the proposal |
|---|---|---|
Scope | Systems in and out, by name | Stops a supplier assuming a smaller job |
Data volumes | Row counts and growth rate | Drives the approach more than anything else |
Data quality | What you know is wrong, honestly | An honest RFP gets an honest price |
Approach | Phased or big bang, and why | Forces a real answer rather than a preference |
Acceptance criteria | How you will verify success | Otherwise success is whatever they delivered |
Rollback | Rehearsed, with a time limit | The criterion most RFPs omit |
Post-migration support | Duration and scope | Decides who owns the first month |
Residency and GDPR | Where data sits and who reaches it | Constrains the supplier list |
The eight sections that make migration proposals comparable.
Being honest about known data problems is counterintuitive and correct. Concealing them does not make them go away, it just moves the discovery of them from procurement into delivery, where the change control clause applies.
Acceptance criteria deserve more thought than they usually get. Reconciliation counts, tolerance for known-bad records, and performance of the target system under real load are all things to agree before the work rather than after it.
UK GDPR Obligations When Moving Personal Data
A migration is the natural moment to stop carrying data you should have deleted, and most organisations miss it.
The ICO sets out that under UK GDPR personal data must be adequate, relevant and limited to what is necessary under Article 5(1)(c), and under Article 5(1)(e) it must not be kept longer than it is needed.
Copying everything into the new system is the path of least resistance, and it carries forward every retention breach you already had. It also makes the new system slower and larger than it needs to be.
Decide what does not travel. Records past retention, duplicates, fields nobody has used in years, and personal data you no longer have a basis to hold. Write that decision into the RFP so suppliers price the filtering rather than assuming a straight copy.
Data Residency and Where the Data Lands
Establish this before the supplier list, because it removes candidates.
Know which country the data will sit in during migration as well as afterwards, since staging environments are frequently somewhere different from production. Know which jurisdictions the delivery team works from, and whether anyone offshore will hold production access.
These are answerable questions and a regulator may well ask them. Choosing where the data lands is a decision worth making before procurement rather than discovering during it.
What to Negotiate for After Go-Live
The month after a migration is when the problems surface, and it is usually the month the contract stops covering.
Negotiate a defined post-migration support period with a scope, rather than a goodwill arrangement. Agree who fixes data defects found in week three, and whether that is warranty work or chargeable.
Agree reconciliation reporting for a period after cutover, so discrepancies are found by a report rather than by a customer complaint. And agree a performance baseline, because a migrated system that is correct and slow is not a successful migration. Database performance after a move frequently differs from the source system even when the data is identical.
Beyond the contract, this is a relationship you will be in for months. Picking a supplier you can live with matters as much as the technical evaluation, and it is the part the scoring matrix cannot capture.
Frequently Asked Questions
Which Data Migration RFPs Attract Vendors With Low-Risk Phased Delivery?
The ones that ask for phasing explicitly, define what a slice is, and make rollback an evaluation criterion rather than a contract clause. Vendors who work that way self-select into an RFP written that way.
Stating your data quality honestly has the same effect. Suppliers offering low-risk phased delivery price against known problems, and the ones who prefer a fixed-price big bang tend to withdraw once the unknowns are on the page.
What is the Best Data Migration Strategy?
The one that matches your data volume, data quality and tolerance for downtime. Big bang suits low volumes, clean data and a business that can absorb a bad weekend. Phased suits high volumes, messy data and operations that cannot stop.
Strategy is the easier half of the problem. Most failures come from the data rather than the approach.
What Does a Data Migration Methodology Actually Involve?
Profiling the source data, mapping fields to the target, defining transformation rules, cleansing or excluding bad records, trial runs into a staging environment, reconciliation, cutover, then post-migration support.
Trial runs are where the schedule is really set. A supplier proposing a single rehearsal before a production cutover is proposing to learn about your data during the cutover.
Which Data Migration Approach Carries the Least Risk?
Phased delivery with a rehearsed rollback and parallel running. It costs more and takes longer, and it means no single failure is unrecoverable.
The risk you are buying down is not technical failure so much as discovering something about the data that invalidates the plan. Phasing gives you somewhere to put that discovery.
What Are Data Migration Best Practices Worth Insisting On?
Profile before you price, and rehearse the rollback rather than documenting it. Define acceptance criteria in advance, and decide what does not travel.
Then reconcile after cutover on a schedule, and agree who owns defects found in the first month.
Which Systems Integrators Offer the Fastest Timelines, and What Am I Trading?
Speed in migration almost always comes from doing less discovery and fewer rehearsals, which moves risk into the cutover rather than removing it. A supplier proposing a materially shorter timeline than the others is usually proposing a different project.
Ask what they have cut to get there. If the answer is profiling, rehearsals or parallel running, you are buying an earlier date and a worse night.
Does the Same Supplier Need to Handle the Application as Well as the Data?
Not necessarily, though someone has to own the seam between them. Where a migration accompanies legacy application modernisation, splitting the two across suppliers creates an interface that nobody is contractually responsible for.
API integration work between the old and new systems during parallel running is usually where that seam bites. Our development practice treats it as part of the migration rather than as a separate workstream, which is the approach our development practice takes generally.
About the Author
Hamish Kerry is the Marketing Manager at Arch, where he's spent the past six years shaping how digital products are positioned, launched, and understood. With over eight years in the tech industry, Hamish brings a deep understanding of accessible design and user-centred development, always with a focus on delivering real impact to end users. His interests span AI, app and web development, and the transformative potential of emerging technologies. When he's not strategising the next big campaign, he's keeping a close eye on how tech can drive meaningful change.
You can catch up with Hamish on LinkedIn
Sources
- National Audit Office, Challenges in using data across government, June 2019. https://www.nao.org.uk/wp-content/uploads/2019/06/Challenges-in-using-data-across-government.pdf
- National Audit Office, Shared service centres, May 2016. https://www.nao.org.uk/wp-content/uploads/2016/05/Shared-services-centres.pdf
- National Audit Office, Digital transformation in government: addressing the barriers to efficiency, March 2023. https://www.nao.org.uk/wp-content/uploads/2023/03/digital-transformation-in-government.pdf
- Information Commissioner's Office, Data minimisation, 2026. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/data-minimisation/
- Government Digital Service, Moving away from legacy systems, 2026. https://www.gov.uk/service-manual/technology/moving-away-from-legacy-systems
- Arch, Discovery, 2026. https://wearearch.com/services/discovery