How to choose a legacy migration partner: 12 questions
Choosing a legacy migration partner comes down to twelve questions in four groups. Method: have they handled your platform generation, how will they learn what the system really does, will old and new run in parallel. Data: how is correctness proved, how is undocumented behaviour handled, what happens to history. Commercials: fixed quote or day rate, what happens if you stop halfway, who owns the code. Aftercare: support costs, the fate of the old system, what they need from you. The sharpest red flags are a quote produced without seeing the system and a big-bang cutover.
Most UK businesses replace a core system once in twenty years; the suppliers quoting for the job do it every month. These twelve questions level that table. Ask all of them, in any order, and take notes.
The answer in one paragraph
You are buying a rescue, not a rewrite. The job is moving a live business off a dying platform without losing a record or a day of trading, and the right supplier behaves accordingly: parallel running rather than a big-bang weekend, proof of data correctness rather than reassurance, code you own on boring technology, staged delivery you keep if things stop, and plain numbers for aftercare. The twelve questions below, grouped under method, data, commercials and aftercare, test exactly that. They are deliberately even-handed: any competent supplier should pass them comfortably, and they are the questions Proctor Digital expects to be judged by too.
Method
1. Have you handled our platform generation before? A good answer names your era and its habits without reaching for notes: DBF tables, 16-bit runtimes, VB6 dependencies, split Access databases. The red flag is “it is all just code”. Every generation has specific traps, and a supplier meeting yours for the first time will be learning them on your system.
2. How will you find out what the system actually does? A good answer involves sitting with the people who use it: walking every screen, listing the reports anyone still reads, asking what gets retyped into spreadsheets. Systems this old are documented mainly in their users’ habits. The red flag is a proposal written from your feature list without asking to watch the system run.
3. Will the old and new systems run in parallel, and for how long? A good answer keeps the old system live and primary while the new one is reconciled against it daily, with cutover waiting until the business is satisfied; how parallel running works sets out the method. The red flag is a big-bang weekend cutover, however confident the testing story sounds.
Data
4. How will you prove the data migrated correctly? A good answer is mechanical: scripted extraction rehearsed in dry runs, then written reconciliation, meaning record counts, financial totals and spot checks a non-technical owner can read. The red flag is “we will be very careful”. Care is a temperament; reconciliation is evidence.
5. How will you handle behaviour nobody documented? A good answer expects it, budgets discovery time for it, and treats every mismatch surfaced during the parallel run as knowledge captured while it is cheap. The red flag is a supplier who assumes the specification is complete and bills every surprise as a change request.
6. What happens to our historical data? A good answer brings all of it across or archives it readably, keeping a raw copy so any migrated value can be traced back to the bytes it came from. The red flag is no curiosity about your data at all: its size, its age, its oddities. The data is the asset being rescued; indifference to it is indifference to the job.
Commercials
7. Fixed quote or day rate, and what moves the price? A good answer is a fixed price set after a proper scoping exercise, with the price-movers named in advance: tables, screens in real use, reports, integrations. A day rate for a short discovery phase is legitimate. The red flag is a confident fixed quote from someone who has never seen the system.
8. What happens if we stop halfway? A good answer is staged delivery in which everything completed stays yours and useful: the audit document, the extracted and verified data, any finished module. The red flag is a structure where nothing has value until the final invoice, which converts your caution into their leverage.
9. Who owns the code, and could another developer take it over? A good answer is that you own it outright and it is built on boring, mainstream technology precisely so an ordinary developer could pick it up; boring is a feature, not a lack of ambition. The red flag is a proprietary framework, licence-tied hosting, or ownership terms that quietly rebuild the dependency you are paying to escape.
Aftercare
10. What does support cost after go-live? A good answer is plain numbers in writing: a warranty period, then optional ongoing support you can decline without the system degrading. The red flag is vagueness, or support that only the original supplier can ever provide.
11. What happens to the old system after cutover? A good answer keeps it available read-only as a fallback until you decide otherwise, then retires it deliberately with its data archived. The red flag is switching it off on day one, which burns the bridge you just paid to keep.
12. What do you need from us, and when? A good answer is an honest list with dates: hours from the staff who use the system, sample data early, decisions at named points. A migration your own people spend no time on will miss how the business actually works. The red flag is “nothing, we will handle everything”, which sounds like service and means nobody intends to listen.
The sharpest six, in one table
| Question | A good answer sounds like | The red flag |
|---|---|---|
| Will old and new run in parallel? | Old system stays primary; daily written reconciliation; the business calls cutover | A big-bang weekend cutover |
| How is the data proved correct? | Dry runs, then reconciliation counts and totals in writing | ”We will be careful” |
| Who owns the code? | You do, outright, on boring mainstream technology | A proprietary framework or licence-tied terms |
| What if we stop halfway? | Staged delivery; every completed stage stays yours | Nothing usable until the final invoice |
| Fixed quote or day rate? | Fixed, after scoping, with the price-movers named | A confident quote before seeing the system |
| What does support cost after go-live? | Plain numbers; ongoing support optional and declinable | Vague, or support only they can provide |
Red flags that end the meeting early
Four patterns disqualify a supplier on their own.
A quote without seeing the system. Nobody can price what they have not measured; a number produced that quickly is a sales figure with change requests attached.
Rewrite-everything enthusiasm on this year’s fashionable stack. If the pitch names more JavaScript frameworks than it asks questions about your data, you have learned what you came to learn.
No curiosity about your data. The records are the point of the exercise. A supplier interested only in the new screens is building a portfolio piece, not rescuing a business.
Contempt for the old system. It kept the lights on for twenty years; respect it, then retire it. Its quirks encode business rules nobody wrote down anywhere else, and a partner who sneers at it will miss them.
The fairest test runs the other way too: a good partner is willing to say “not yet”. Staying put or refactoring sometimes genuinely wins, a comparison we make honestly in rewrite, refactor or replace, and a supplier who can never reach that conclusion is selling, not advising.
How to use this list
Take it into every meeting, ours included; the questions work whoever sits across the table. For what the answers should cost, what legacy system replacement really costs in the UK sets out the ranges we actually quote. If you would rather have the early questions answered in writing before committing to anything, that is what the fixed-price Rescue Roadmap produces, and the free Legacy Risk Audit comes before even that: a 30-minute call and a one-page written risk summary of where your system stands. Twelve questions, four groups, one afternoon of meetings; judge every supplier against them, and judge us first.