How to Choose a Legacy Modernization Partner

Quick summary

• The single most useful question is how the legacy modernization partner establishes what the system currently does before changing it. No answer to that means no safety net.

• Ask for the rollback design, not the migration plan. Anyone can draw a migration plan.

• A fixed quote given before the codebase has been examined is a package price, not an estimate for your system.

• Modernization selection criteria are not the same as general development vendor criteria; knowing how to choose a modernization vendor is essential. The differences for legacy system modernization companies are all about handling what nobody documented.

Modernization work fails differently from greenfield work. A new build fails visibly: it is late, or it does not do what was asked. A 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. That is what these criteria are designed to surface.

1. How do you establish current behaviour before changing anything?

This is the question that separates modernization from rewriting for an application modernization services company. A legacy system’s real specification is its behaviour, including the parts nobody documented and some the business has forgotten. A partner who intends to work from the existing documentation and a requirements workshop is planning 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.

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 2am 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.

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.

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 worry 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.

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.

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 engineers on the assessment are the engineers on delivery, and whether you speak to them or to an account layer.

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 programmers.

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.

The two answers that should end the conversation

A fixed price for the full programme before anyone has read the code. It 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.

A recommendation to rewrite from scratch made before the assessment. It is occasionally the right answer, but it can only be the right answer after somebody has established whether the business logic is worth keeping.

A short scoring frame 

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, including the explicit list of what we propose not to touch. A business that takes that and delivers in-house has had a useful engagement. 

Frequently Asked Questions

Should we choose a specialist or our existing development partner? 

Existing partners carry real advantage in business context and lose it if they have not done incremental migration before. The behavioural-baseline question in section one is the fastest way to tell which you have. 

How much should a modernization assessment cost? 

We are not publishing a figure yet. What you should expect is that an assessment is priced separately from delivery and produces a deliverable you keep regardless of what you do next.

Is offshore delivery viable for modernization work? 

It depends far less on location than on whether the engineers doing the work have direct access to the people who know the system. Undocumented behaviour is recovered through conversation, and anything that slows those conversations slows the project. 

How do we compare proposals that recommend different approaches? 

Compare the reasoning, not the recommendation. Each should state which constraint it is solving. A proposal that cannot name the constraint is describing a service, not a solution to your problem.

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.