Questions to ask a legacy application modernization services vendor before you sign

Ask a legacy application modernization services vendor six things before you sign: show me a programme you actually cut over, how will the old and new systems run side by side, who owns the code and prompts at the end, what does this cost to run rather than to build, who answers at two in the morning, and what happens if we want out. A vague answer to any of them is the finding.

Below is the full question set we would use if we were the buyer, grouped by what each question is really testing, with the answers that should reassure you and the ones that should not.

Why the questions matter more than the quote

Two vendors quoting the same scope at similar prices can produce completely different outcomes, because a modernisation programme is mostly a sequence of judgement calls made after the contract is signed. Which module moves first. What happens to the records that will not reconcile. Whether the team tells you early that a date is at risk. A quote cannot express any of that. The way a vendor answers an uncomfortable question can.

Treat this as a structured interview, not a checklist to tick. Ask the questions with the delivery lead in the room rather than the salesperson, and ask for one concrete example after each answer. Generalities are cheap; specifics come from having done the work.

Evidence: have they shipped a modernisation before?

Start here, because everything else is easier to fake. Ask: name a legacy programme you took all the way through cutover, and tell me what went wrong on it. A vendor who has genuinely done this will have a story about a bad data migration, a delayed go-live or a rollback, and will tell it without flinching. A vendor whose answer is uniformly positive has either not done it or will not tell you when yours goes sideways.

Follow with: what was the incumbent system, and who built it? Modernising a COBOL batch system, a fifteen-year-old Java monolith and a heavily customised ERP are three different disciplines. Then ask what the client's own team had to do, because a vendor who cannot describe the buyer's effort has probably never been through a real reconciliation cycle.

Coexistence: how will old and new run together?

Ask the vendor to draw, on a whiteboard, how the two systems will coexist during the programme. You are listening for two named things: an anti-corruption layer that stops the legacy data model leaking into the new one, and an interface that stays stable while what is behind it is replaced. If they describe the strangler-fig pattern without being prompted, that is a good sign. If the plan is a single cutover weekend, ask what the rollback looks like, and keep asking until you get a rehearsed answer.

Then ask how they will prove the new module behaves like the old one. The correct answer involves characterisation tests written against the legacy system's actual behaviour, including its bugs, and shadow running with both systems processing real traffic and their outputs compared. If there is an AI component, ask what the evaluation suite contains and who signs off its pass threshold.

Ownership: what do you hold at the end?

Ask directly: at handover, do we own the source code, the infrastructure definitions, the prompts, the model choices and the documentation, with no licence-back and no runtime dependency on your platform? The answer should be an unqualified yes. At Eazyware it is: you own code, infrastructure, prompts, model choices and documentation, and we sign the NDA before the first working session.

The follow-up matters more. Ask whether any part of the running system calls a service the vendor hosts. Wrappers, orchestration layers and prompt-management consoles that sit in the vendor's tenancy are how a fixed-price build becomes an annual dependency. Ask for the list in writing.

Money: what does it cost to run?

The build price is in the quote. Ask for the three numbers that are not. First, who pays for AI API usage and on whose account; the honest answer is that you pay through your own accounts, with budgets, routing and dashboards set up so it stays predictable. Second, how long the incumbent stays live and who renews its licence in that window. Third, what the support contract costs by tier, and whether the quoted response time is response or resolution, which are different things. What a fixed-price AI quote should contain lists the clauses worth insisting on.

The question grid

People and escalation

Ask who, by name, will lead delivery, how much of their week you get, and what happens if they leave. Ask what the escalation path is when a release breaks something in production on a Friday evening, and ask for the actual phone-tree rather than the phrase "we have a 24x7 process". Then ask how often the two of you will meet, who chairs it, and what is on the agenda. A weekly meeting with a written decision log is worth more than a monthly status deck.

Security questions belong in this block too. Ask where data is processed, how access is scoped, and, if there is an AI component, what controls exist against prompt injection and data leakage through model context. The OWASP Top 10 for LLM applications is the reference a serious vendor will already be working from, and our own security questionnaire for AI vendors turns it into a document you can send.

The list to paste into your evaluation

• Evidence. Name a legacy programme you cut over, and describe what went wrong on it.
• Incumbent fit. What kind of legacy system was it, and how close is it to ours?
• Coexistence. Draw how old and new run together, and name the pattern you use.
• Parity. How do you prove the new module behaves like the old one, including its quirks?
• Rollback. What is the rollback plan for each cutover, and has it been rehearsed?
• Ownership. Do we own code, prompts, infrastructure and documentation outright?
• Dependencies. Does anything in the running system call a service you host?
• Running cost. Who pays for model usage, and what is the assumed parallel-running window?
• Support. What are the response and resolution SLAs by severity, and what hours?
• Exit. What does handover include, and what does a transition out cost?

Questions that sound rigorous and tell you nothing

Some standard due-diligence questions produce no signal. "How many engineers do you have?" tells you about the vendor's size, not your team's quality. "Are you certified in X?" tells you a process document exists. "What is your defect density?" invites a number nobody can verify. "Do you use AI in delivery?" is now answered yes by everyone.

Replace them with questions that have a wrong answer. "What would make you tell us not to do this project?" is the best single question in the set, because a vendor who cannot name a scenario in which they would decline the work is selling, not advising. We decline modernisation work where a commercial product covers the need outright, and you should expect the same candour from anyone you shortlist.

What our answers are

For transparency, here is how we answer our own questions. The Legacy-to-AI Modernization Program is fixed price from $31,500 or ₹22,40,000 to $105,000 or ₹72,00,000 and above, scoped against a locked statement of work. Care Plans after launch run from $1,000 or ₹68,000 a month for business-hours IST cover to $5,250 or ₹3,40,000 for 24x7 cover with one-hour response and a named engineer, with a $750 or ₹40,000 AI add-on for evals, cost monitoring and prompt regression. All of it is published on the pricing page. You own everything at handover, you pay for model usage on your own accounts, and about half our work is paired with the client's internal team with documented handover.

Where the questions changed a decision

On a university ERP programme, the coexistence question was the one that mattered. The system covered admissions, fees and examinations, and no single weekend existed in the academic calendar when all three could safely move. A vendor promising a big-bang cutover would have been wrong on week one. Replacing capability module by module behind a stable interface, around the institution's own cycle, is what made the programme deliverable, and it is described in the university ERP modernisation case study.

Related reading

What to put in a legacy application modernization services RFP turns these questions into a document, Five ways legacy application modernization services projects fail describes what the weak answers lead to, and Application modernization vs rewrite covers the decision that sits behind the vendor choice. If you want to put these questions to us, start a conversation.

Interview the delivery lead, not the deck, and shortlist the vendor who tells you the worst thing first.