Questions to Ask Before Hiring a Legacy Modernization Partner

For: A COO or CIO at a 200–1,000-person business whose core operations still run on a 10–15-year-old system — ERP, custom desktop app, or Access database — who has budget approval to modernize but has never run a project like this before and is about to shortlist vendors

The single question that separates a real legacy modernization partner from a greenfield shop wearing the label is this: how do you establish a source of truth when the legacy system's behavior contradicts its own documentation and the original developers are gone? Every vendor will claim legacy experience in the pitch deck. Only the ones who have actually reverse-engineered a live system have a specific, procedural answer. Everything else in this list is a variation on that same test — can they handle the reality that your system is the documentation, and no one alive fully understands it.

What follows is the interview kit. Use it in the second meeting, not the first. The first meeting is theater; the second is where you find out whether you're hiring engineers or storytellers.

Discovery and reverse-engineering

1. How do you establish a source of truth when documentation contradicts runtime behavior?

Why it matters: This is the whole game. In a 10–15-year-old system, documentation is aspirational, tribal knowledge left with people who quit, and the code has been patched by six generations of developers. The system's actual behavior — including its bugs that the business now depends on — is the spec.

Good answer: They describe a specific process: production traffic capture, database query log analysis, running the legacy system in a shadow environment, interviewing power users about edge cases, and treating observed behavior as authoritative over any written doc. They mention specific tools (Wireshark, SQL profilers, event sourcing, characterization tests).

Red flag: "We'll review your documentation and interview stakeholders." That's a greenfield discovery process. It will miss every undocumented business rule.

2. Walk me through a time the legacy system did something no one could explain.

Why it matters: Every real modernization has this moment. If they can't tell you the story, they haven't lived it.

Good answer: A specific anecdote — a pricing rule buried in a stored procedure, a nightly batch job no one knew existed, an Access macro that silently reconciled two ledgers. They tell you how they found it and what they did.

Red flag: Generic answers about "technical debt" or "legacy complexity." No story means no scars.

3. What percentage of your engagement is discovery vs. build?

Why it matters: On a real legacy re-platform, discovery is not a two-week phase. It runs in parallel with build for most of the project.

Good answer: Discovery is continuous and iterative. They budget for surprises. They can describe how they revise scope when discovery uncovers business logic no one knew was in there.

Red flag: A crisp "discovery phase" followed by a locked-scope build phase. That means the first surprise will trigger a change order or blown timeline.

Business logic preservation

4. How do you decide which existing behaviors are bugs vs. features the business depends on?

Why it matters: Half the "bugs" in a legacy system are load-bearing. Fixing them breaks downstream processes no one told you about.

Good answer: They default to preserving observed behavior and flagging anomalies for business review before changing them. They keep a decision log. They involve the business users who actually work with the system daily.

Red flag: "We'll clean up the bugs as we rebuild." That is a promise to break your operations.

5. How do you handle undocumented integrations?

Why it matters: Old systems have integrations no one remembers — a CSV dropped on an FTP server at 2 a.m. that a partner picks up, an email parser, a screen scraper.

Good answer: Network monitoring, file system audits, port scans, review of scheduled tasks and cron jobs, interviews with IT ops about outbound traffic. They assume they will find integrations no one has mentioned.

Red flag: They ask you for a list of integrations and plan from that list.

6. Show me a characterization test suite from a previous engagement.

Why it matters: Characterization tests capture what the legacy system does, not what it should do. They are the safety net for any re-platform. If the partner doesn't write them, they're rebuilding blind.

Good answer: They can show anonymized examples. They can explain how they generate test inputs from production data and how they compare legacy and new outputs during parallel-run.

Red flag: They talk about unit tests and acceptance criteria but not about tests that pin down existing behavior.

Migration and cutover

7. What is your parallel-run strategy?

Why it matters: Big-bang cutover on a business-critical legacy system is malpractice. You need the old and new running side-by-side, with output comparison, for long enough to trust the new one.

Good answer: Shadow mode, dual-write, output diffing, gradual traffic shifting by user cohort or transaction type. They can describe how they handled discrepancies in a previous project.

Red flag: "We'll do UAT and then cut over on a weekend."

8. How do you migrate data when the legacy schema has 15 years of accumulated inconsistency?

Why it matters: Real legacy databases have orphaned records, three different ways to represent "cancelled," NULLs where there shouldn't be any, and encoding issues. A migration script that assumes clean data will corrupt yours.

Good answer: Data profiling first, reconciliation rules signed off by the business, migration in reversible stages, checksums and row-count validation, a rollback plan.

Red flag: An ETL diagram and a confident timeline.

9. What's your rollback plan if the new system fails in production week one?

Why it matters: If they haven't thought about rollback, they haven't thought about risk.

Good answer: The legacy system stays live and writable for a defined period. Data written to the new system replicates back. They have a documented decision tree for when to roll back vs. patch forward.

Red flag: "We'll fix issues as they come up."

Team, IP, and commercial

10. Who specifically will be on my team, and can I interview them?

Why it matters: Sales engineers are not delivery engineers. Bait-and-switch is the oldest trick in services.

Good answer: Named engineers, their prior legacy work, and a meeting scheduled before contract signature. The tech lead should be able to talk about your specific stack.

Red flag: "We'll assign the right team once we start."

11. Do I own the source code, the models, the data pipelines, and the deployment infrastructure — fully?

Why it matters: Some partners keep partial IP, or lock you into their proprietary framework, or host on infrastructure only they can access. That's a new form of the same lock-in you're trying to escape.

Good answer: Full IP transfer, code in your repos from day one, infrastructure in your cloud accounts, no proprietary runtime dependencies. This is the model firms like CodeNicely operate on and it should be table stakes.

Red flag: Any hedging on IP ownership, or a "platform" you'd need to keep paying for.

12. What happens if I want to fire you at month four?

Why it matters: The answer tells you how much leverage they plan to have over you.

Good answer: A clean exit clause, documentation and handover obligations written into the contract, code and infrastructure already in your possession, and a named internal or third-party team that could pick it up.

Red flag: Vague answers, or terms that require you to buy out the remaining engagement.

13. Show me two references from legacy modernization projects — not greenfield builds.

Why it matters: Portfolio pages blur the two. Ask specifically for re-platforming, not new product builds.

Good answer: Two references with named contacts, specific legacy stacks (AS/400, VB6, classic ASP, on-prem Oracle, Access), and permission to ask hard questions. Case studies like GimBooks or Vahak are useful for evaluating build capability, but for modernization you want references specifically about re-platforming live systems.

Red flag: Only greenfield case studies, or references who worked on "digital transformation" projects that turn out to be new customer portals bolted onto the old system.

14. How do you price the unknown?

Why it matters: Fixed-price contracts on legacy modernization either become adversarial (every surprise is a change order fight) or the vendor pads so heavily you overpay. T&M without guardrails is open-ended.

Good answer: A hybrid — fixed price for well-scoped phases, T&M with caps for discovery-heavy phases, and a joint change-control process. They talk about how they've handled scope surprises without breaking the relationship.

Red flag: A confident fixed price on day one for the whole engagement. They're either lying or they'll cut corners.

15. What do you refuse to do?

Why it matters: Partners who say yes to everything haven't thought hard about tradeoffs. A senior team has opinions and will push back.

Good answer: Specific refusals — "We won't do big-bang cutovers on transactional systems." "We won't skip characterization tests to hit a date." "We won't rebuild in a framework we can't hand off cleanly."

Red flag: "We'll do whatever you need." That's a sales answer, not an engineering one.

How to score the answers

You are looking for specificity. A capable partner answers with tools, procedures, and stories. A greenfield shop dressed up for the pitch answers with frameworks, methodologies, and adjectives. Two or three vague answers on the questions above and you should keep shortlisting. The cost of a bad modernization partner is not the fee — it is the eighteen months of stalled operations you can't recover.

One more thing: bring a technical person to these meetings. Not a CTO from another company, an actual engineer who has worked inside your legacy system. They will hear things a procurement lead won't.

Frequently Asked Questions

What's the difference between legacy modernization and a rewrite?

A rewrite starts from requirements and builds new. Modernization starts from an existing live system whose behavior must be preserved — including undocumented rules the business depends on. The disciplines are different: modernization requires reverse-engineering, characterization testing, and parallel-run infrastructure that rewrites don't need.

Should I modernize incrementally or all at once?

Incrementally, almost always. The strangler-fig pattern — where new services gradually replace pieces of the old system while both run in parallel — reduces risk dramatically compared to a full rebuild-and-cutover. The exception is systems so tightly coupled that no clean seam exists, and even then the answer is usually to create a seam first.

How do I evaluate a legacy migration vendor if my internal team has never done this before?

Hire an independent technical advisor for the vendor-selection phase — a consultant or fractional CTO who has personally led a modernization. Two days of their time to sit in on vendor meetings and review proposals will catch issues your team can't. Then use the 15 questions above as your interview framework.

What if the original developers of our legacy system are unreachable?

This is the normal case, not the exception. A capable partner treats the running system as the source of truth and works from production behavior, database contents, and current user workflows. If a vendor's plan depends on interviewing the original developers, they don't have a real methodology.

How much should we budget for legacy modernization?

Cost depends heavily on system complexity, integrations, data volume, and how much business logic is undocumented. Rather than working from a generic range, get a scoped assessment. Contact CodeNicely for a personalized assessment based on your actual system.