Choosing a legacy modernization partner: eight questions that matter
Modernization work fails differently from greenfield development. A new build fails visibly: it is late or does not do what was asked. A legacy modernization programme fails quietly, months later, when a behaviour nobody knew about stops happening and the reconciliation that would have caught it was never run. Choosing a partner who surfaces these hidden risks before work starts means the difference between a successful modernization and a silent one.
1. How do you establish current behaviour before changing anything?#
This question separates modernization from rewriting. A legacy system's real specification is its behaviour, including the parts nobody documented and some the business has forgotten. A partner working from existing documentation and a requirements workshop plans to rebuild what people remember, not what the system does.
Strong answers involve characterisation tests, traffic capture and replay, or reconciliation against production output. Weak answers talk about understanding your requirements. This question identifies whether they will discover what actually happens or only what they are told happens.
2. What is the rollback design at each stage?#
Ask not for the migration plan but for what happens when a stage goes wrong at two in the morning on a Tuesday. A partner working incrementally will describe the old path remaining available and traffic moving back. A partner planning a cutover will describe a restore from backup, which for a transactional system means losing whatever happened since the last backup.
Incremental approaches preserve the old system as a safety net. Cutover approaches make the old system a single point of failure. The rollback design shows which category the partner is in.
3. Do you propose one approach or several?#
A proposal that applies one approach uniformly across a large system has usually not looked closely. Different components carry different constraints. Expect a per-component recommendation, and expect at least one component where the answer is leave it alone for now.
A good assessment produces a detailed breakdown showing why each component needs its own strategy. A generic one-size-fits-all approach flags a partner who is selling a service rather than solving your problem. See how enterprise software development is tailored to your architecture for comparison.
4. How is data migration verified?#
The answer you want includes reconciliation at both ends and a report proving parity between source and target. The answer that should concern you is that data is migrated and then spot-checked. Unverified migrations surface months later inside a report nobody can explain, at which point the original system may already be gone.
Verification is about proving the data arrived correctly and completely. Spot-checking finds obvious errors but misses systematic problems that only show up at scale.
5. What happens to the knowledge?#
Modernization that leaves you with a modern system nobody in-house understands has moved the dependency rather than removed it. Ask what documentation is produced, whether architecture decisions are recorded with their reasoning, and what the handover to your team actually involves.
Knowledge transfer is not a support retainer. It is a working understanding of why the system was rebuilt the way it was, captured in architecture decision records and documented in a form your team can maintain and evolve.
6. Who is doing the work, and do they talk to us?#
In this category the people who assessed the system and the people who change it should overlap substantially. Ask directly whether the software engineers on the assessment are the software engineers on delivery, and whether you speak to them or to an account layer.
A partner where the assessment team hands off to a different delivery team has split the knowledge. Direct software engineer access means the people who understand your system are the ones building the replacement.
7. What are you not going to change?#
A good assessment produces an explicit list of what is deliberately being left alone, and can defend each item. A partner with no such list either has not scoped the work or intends to change everything, which is the scope failure that kills these projects.
A do-not-change list shows boundaries. It tells you what stays as a stability anchor while other parts are modernized. A complete rewrite disguised as modernization is expensive and risky.
8. What are the commercial terms on IP, data and exit?#
Who owns the code that gets written, where does your data sit during migration, and what happens if you stop the engagement after stage two. These should be answerable in a sentence each. Clear answers show a partner who has thought through the business side of the engagement.
Vague commercial terms create disputes when circumstances change. Explicit terms mean you know where you stand if you need to exit or pivot mid-project.
A short scoring frame#
Use this frame to compare proposals side by side. Each column shows what a strong signal and a weak signal look like.
| Criterion | Strong signal | Weak signal |
|---|---|---|
| Behavioural baseline | Strong signalCharacterisation tests, replay, reconciliation | Weak signalRequirements workshops and existing docs |
| Rollback design | Strong signalOld path live, traffic reversible per stage | Weak signalRestore from backup |
| Approach | Strong signalPer-component recommendation | Weak signalOne method across the entire estate |
| Data verification | Strong signalParity report at both ends | Weak signalMigrate then spot-check |
| Knowledge transfer | Strong signalADRs, documentation, handover sessions | Weak signalSupport retainer only |
| Team continuity | Strong signalAssessors deliver, direct software engineer access | Weak signalAccount manager intermediary |
| Scope clarity | Strong signalExplicit do-not-change list | Weak signalEverything in scope |
| Commercials | Strong signalClear IP, data location, exit terms | Weak signalAnswered later |
The answers that should end the conversation#
A fixed price for the full programme before anyone has read the code is not an estimate for your system. It is the price of their standard package, and the gap between the two gets recovered through change requests later.
A recommendation to rewrite from scratch made before the assessment is occasionally the right answer, but only after somebody has established whether the business logic is worth keeping. A rewrite pitched before that discovery is a solution looking for a problem.
What this looks like with Atyantik#
Our assessment is a standalone deliverable: a dependency map, a ranked risk register, a per-component recommendation and a sequenced plan with rollback points. We include the explicit list of what we propose not to touch. A business that takes that and delivers in-house has had a useful engagement. We support your team through the work or deliver the whole programme, your choice.
One more question: what if we only want part of the system modernized?#
That is the more common engagement and usually the better one. Most systems have one component carrying most of the cost. Modernizing that component while leaving the rest stable is often a lower-risk, faster path to the outcome you need. Ask your candidate whether they can scope and deliver partial modernization without refactoring the rest of the system. When you evaluate options, choosing a custom software development company covers the broader partnership evaluation criteria.
For a deeper look at what that engagement looks like, see how Atyantik approaches legacy system modernization and assessment. Timeline expectations matter too: how long custom software development takes applies to modernization as well.