Questions to Ask Before Hiring a Legacy Modernization Partner

For: A COO or CIO at a mid-market company (100–500 employees) who has been burned by one failed legacy migration attempt and is now re-entering the vendor selection process with a live system they cannot afford to break

If you've been burned once by a legacy modernization project, the single most useful question you can ask a prospective vendor is not how do you migrate data — it's how do you extract and validate business logic buried in stored procedures, Excel macros, and the heads of people who left the company. That question separates partners who've actually done live cutovers from teams who've re-platformed a greenfield app and slapped 'modernization' on the pitch deck. Below are 15 questions structured to expose that difference before you sign anything.

Read them as an interview prep sheet. For each one you get a reason it matters, what a real answer sounds like, and the language that should make you politely end the meeting.

Discovery & business logic extraction

1. How do you inventory business logic that lives outside the codebase?

Why it matters: In systems older than ten years, a meaningful portion of your rules live in stored procedures, SSIS packages, cron jobs, Excel macros ops teams built themselves, and undocumented email approvals. If the vendor only maps the code, they'll ship a system that fails silently on edge cases nobody remembered to mention.

Good answer: They describe a discovery phase that includes database object scanning (stored procs, triggers, views), interviewing ops and finance users, shadowing daily workflows, and cataloging every scheduled job on the servers. They mention tools like static analysis on the SQL layer or dependency graphing.

Red flag: "We'll work from your requirements document" or "Our BAs will interview stakeholders." That's requirements-gathering, not archaeology.

2. Walk me through the last time you found a critical business rule that wasn't in the spec.

Why it matters: Real modernization projects always uncover them. If the vendor can't tell a specific story, they haven't done this work.

Good answer: A specific anecdote — a tax-calculation quirk in a stored procedure, a rounding rule embedded in a legacy report, a manual override the CFO does every quarter-end. They explain how they discovered it and how they preserved it.

Red flag: Generic answers about "thorough analysis" without a concrete example.

3. Who from your team will interview our long-tenured employees, and what's their background?

Why it matters: The tribal knowledge extraction only works if the person doing the interview understands both the business domain and the technical stack. A junior BA won't catch the significance of a five-year-old workaround.

Good answer: A named senior engineer or solutions architect who's led at least two prior modernizations, ideally in your industry.

Red flag: A rotating cast of BAs with no domain grounding, or the pitch team disappearing after signature.

Live cutover experience

3. Describe a cutover on a system that couldn't go offline. What went wrong?

Why it matters: Every real cutover has something go wrong. The question isn't whether they've had incidents — it's whether they'll tell you about them.

Good answer: A specific story with a specific failure mode (bad data in a legacy table nobody flagged, a downstream integration that broke, a rollback triggered at 3am). They walk you through detection, response, and what they changed in their playbook after.

Red flag: "Our cutovers have been smooth" or a pitch about zero-downtime methodology with no incident stories.

4. What's your rollback plan and how many times have you had to use it?

Why it matters: A rollback plan that has never been rehearsed is a document, not a plan.

Good answer: They describe a tested rollback with defined decision points, a time budget ("if we're not through validation by hour 4, we roll back"), and a stakeholder who owns the go/no-go call. They admit to using it at least once.

Red flag: Vague reassurance, or a rollback plan that depends on a full database restore they've never rehearsed under load.

5. How do you handle dual-write or parallel-run periods?

Why it matters: The strangler-fig pattern and parallel-run validation are what let you cut over without betting the business on a single weekend. If the vendor doesn't reach for these instinctively, they're planning a big-bang.

Good answer: They discuss shadow reads, dual writes with reconciliation jobs, feature-flag driven traffic shifting, and how they compare outputs between old and new systems over weeks — not hours.

Red flag: A cutover plan that fits on one slide and mentions a "go-live weekend."

6. What's the longest parallel-run period you've operated?

Why it matters: Real modernizations run parallel for weeks or months on high-risk paths. Short parallel runs suggest they trust their migration more than they should.

Good answer: Weeks to months, with a clear description of what reconciliation looked like and what discrepancies they caught.

Red flag: "A few days to make sure everything works."

Data & integration

7. How do you validate data migration beyond row counts?

Why it matters: Row counts match. Totals don't. That's the classic legacy migration failure.

Good answer: They talk about checksum comparisons, financial reconciliation reports run against both systems, sampling with domain-expert review, and business-outcome validation (does the month-end close produce the same numbers?).

Red flag: "We ran the ETL and validated record counts."

8. How do you handle integrations with systems we don't control?

Why it matters: Your legacy system probably talks to a bank, a regulator, an EDI partner, or a 20-year-old SAP install owned by a customer. These integrations are where cutovers break.

Good answer: They inventory external dependencies early, insist on sandbox testing with each partner, and plan integration cutover independently from the main system cutover.

Red flag: They assume all integrations can be re-pointed at go-live.

9. What happens to our historical data — do we keep the old system read-only?

Why it matters: Regulatory retention, audits, and customer disputes reach back years. A modernization that dumps historical data without a plan creates a downstream mess.

Good answer: They propose either full history migration with archival tiering, or a read-only preservation of the legacy system for a defined window with a clear sunset plan.

Red flag: "We'll migrate the last 2 years and archive the rest." That decision should be yours, not theirs.

Team, ownership, and lock-in

10. Who owns the IP and source code?

Why it matters: Some vendors retain rights to frameworks or accelerators they embed in your codebase. You find out during a dispute.

Good answer: You own everything, full source, no runtime dependencies on the vendor's proprietary platform. Any third-party libraries are open source or licensed to you directly.

Red flag: A "platform" or "accelerator" the vendor licenses to you. That's lock-in dressed as speed.

11. What does the handover to our internal team look like?

Why it matters: If you can't run the new system without them, you've swapped one legacy dependency for another.

Good answer: Documented handover with runbooks, architecture decision records, pairing sessions with your engineers during build (not just at the end), and a defined support taper.

Red flag: Handover is a two-week training at the end. Or worse, an ongoing managed-services contract you can't opt out of.

12. Who specifically will be on the project, and can I interview them?

Why it matters: Pitch teams and delivery teams are often different people. You want to meet the tech lead who'll actually own the cutover.

Good answer: Named people, resumes, and a call with the proposed tech lead before contract.

Red flag: "We'll assign the right resources at kickoff."

13. What's your team's turnover on projects longer than 12 months?

Why it matters: Modernization projects that lose their tech lead mid-flight are the ones that fail. You're not paying for a logo — you're paying for continuity of context.

Good answer: Honest number, plus a description of how they handle rotations (overlap periods, documented context transfer).

Red flag: "We have very low turnover" with no number attached.

Risk and honesty

14. What's the failure mode of your recommended approach — what is it bad at?

Why it matters: Every approach has tradeoffs. Strangler-fig is slow. Big-bang is risky. Rewrite is expensive. A vendor who can't name their approach's weaknesses hasn't thought hard enough.

Good answer: A clear tradeoff — "strangler-fig will extend our timeline and require you to maintain both systems in parallel; if your legacy stack is already unstable, that's a bad bet."

Red flag: "Our approach is designed to minimize all risk."

15. Can I talk to a reference where the project went badly?

Why it matters: Every experienced vendor has one. The question tests honesty.

Good answer: They either give you one, or they explain — specifically — a project that went sideways and what they learned. Some will offer a reference at a client where the scope was cut, the timeline slipped, or the initial approach was wrong.

Red flag: All references are glowing and all projects went to plan.

How CodeNicely can help

CodeNicely runs legacy modernization for mid-market and enterprise clients where the live system cannot break. The closest reference for a burned-once buyer is GimBooks, a YC-backed accounting SaaS where we owned the modernization of a system used daily by small businesses to file GST returns — meaning any downtime or logic error hit real tax filings. The work required exactly the kind of stored-procedure archaeology and parallel-run validation described above, not a greenfield rebuild.

Our commitments: full IP ownership, no proprietary platform lock-in, named senior engineers on your project (interview them before you sign), and a delivery model that pairs our team with yours so the handover is continuous, not a two-week training at the end. If you're re-entering vendor selection after a failed attempt, we'd rather have an honest discovery conversation about what actually broke last time than send a pitch deck.

The one takeaway

If you ask only one of these questions, ask #1: how they extract business logic that lives outside the codebase. A vendor who has real answers for stored procedures, Excel macros, and tribal knowledge has done this before on a live system. A vendor who talks about "requirements gathering" is going to rebuild what they can see and quietly break what they can't.

Frequently Asked Questions

How long should the discovery phase be before committing to a modernization approach?

Long enough that the vendor can defend their proposed architecture with evidence, not opinion — which means enough time to inventory database objects, interview power users, and map external integrations. For a specific scope estimate on your system, contact CodeNicely for a personalized assessment.

What's the difference between re-platforming and true modernization?

Re-platforming moves the same architecture to newer infrastructure — a lift-and-shift to the cloud, or a language port. True modernization redesigns the system's boundaries, extracts embedded business logic into explicit services, and typically decouples the data layer. Re-platforming is faster and lower-risk; modernization is what you do when the underlying design is what's holding you back.

Should we rewrite from scratch or use the strangler-fig pattern?

Strangler-fig is the safer default for any system your business depends on daily, because it lets you migrate incrementally with rollback options. Full rewrites make sense when the legacy system is small, well-understood, or so unstable that maintaining it in parallel is riskier than replacing it. Any vendor who defaults to full rewrite without asking about your operational risk tolerance is not thinking about your business.

How do we protect ourselves from vendor lock-in during modernization?

Contractually require full source ownership, avoid vendor-proprietary frameworks or runtime platforms, insist on open-source or directly-licensed dependencies, and require documented handover with runbooks. If the vendor's speed comes from a "platform" you don't own, you're renting your own system back from them.

What's the biggest reason legacy modernization projects fail?

Underestimating the business logic buried outside the codebase — in stored procedures, ops team spreadsheets, undocumented manual steps, and the memory of long-tenured employees. Projects that go straight from a requirements document to a rebuild consistently miss rules that only surface after cutover, when the numbers stop matching.