Re-engineering a legacy system is riskier than building something new, because you inherit decades of undocumented business logic while trying to keep the lights on. The right partner treats that risk as the central problem to solve.
Legacy system re-engineering is a fundamentally different discipline from greenfield software development, and it is a mistake to evaluate potential partners as though the two were interchangeable. A legacy re-engineering project inherits every business rule, workaround, and undocumented edge case embedded in a system that has often run unchanged for a decade or more, frequently maintained by an original developer who left the organization years ago. The partner you select has to be as skilled at forensic reverse-engineering of existing behavior as they are at writing new, modern code.
We have seen this go wrong in a very specific and expensive way: a vendor rebuilds the system faster and cleaner than the incumbent, cuts over, and only then discovers that the new system does not replicate a critical edge case that finance, operations, or a regulatory report quietly depended on for years. The business impact of that gap is often disproportionate to how small the missed requirement seemed in isolation. Selecting the right re-engineering partner is largely about selecting a partner who is structurally set up to catch that kind of gap before go-live, not after.
Ask any prospective partner, in detail, how they extract business logic from a legacy system that has little or no documentation. A credible answer will involve a structured combination of code analysis, database schema archaeology, interviews with long-tenured staff who understand the system's quirks, and analysis of historical transaction data to surface edge cases that only occur under specific, infrequent conditions. Vendors who describe this phase vaguely, or who plan to compress it into a two-week discovery sprint before jumping straight into rebuild, are underestimating one of the highest-risk parts of the entire engagement.
It is worth asking specifically how the partner plans to validate that the re-engineered system reproduces the legacy system's actual behavior, not just its documented or assumed behavior. Techniques like parallel-running the old and new systems against live data and reconciling outputs, or building an extensive regression suite derived from historical transactions, are strong signals of a partner who understands where the real risk in this category of project lives. A partner who cannot describe a concrete validation methodology is asking you to trust that they got the business logic right without offering evidence.
Full big-bang rewrites of legacy systems have a well-documented, poor track record across the industry, largely because they concentrate risk into a single, high-stakes cutover event after months or years of development with no opportunity to course-correct. A capable re-engineering partner will propose a phased approach: identifying discrete modules or capabilities that can be re-engineered, validated, and cut over independently, with the legacy and modernized components coexisting through an integration layer during the transition. This dramatically reduces the blast radius of any single mistake and gives the business the ability to validate real-world behavior incrementally rather than betting everything on one cutover weekend.
Ask a prospective partner to propose a phasing strategy specific to your system during the sales process, before any contract is signed. Their ability to identify sensible module boundaries, sequence them by risk and business value, and articulate what stays on the legacy platform during each phase is one of the clearest available signals of whether they have actually done this kind of work before, as opposed to describing it convincingly. This kind of staged, risk-aware delivery is central to how we approach every re-engineering engagement, because a legacy system's business value depends entirely on it staying operational throughout the modernization process, not just at the end of it.
One of the most underrated risks in legacy re-engineering is trading one form of key-person dependency for another. If the only people who understand the newly re-engineered system's architecture are the vendor's consultants, you have not actually reduced your organizational risk — you have transferred it from an aging legacy system to a new vendor relationship. Ask directly how the partner plans to transfer architectural and operational knowledge to your internal team, what documentation they commit to producing, and whether the engagement includes structured training or shadowing periods for your engineers.
Finally, ask about their track record specifically with re-engineering projects, not custom development in general. The two disciplines share tools but differ substantially in risk profile, and a portfolio full of impressive greenfield builds does not necessarily indicate competence at the much harder problem of safely replacing a system that a business already depends on. Request references from re-engineering projects specifically, and ask those references pointed questions about what surprised them during the engagement and how the vendor responded when something did not go according to plan.
Legacy re-engineering rewards partners who are methodical, slightly paranoid about hidden business logic, and structurally biased toward incremental validation over big, impressive cutovers. Those traits rarely show up in a polished sales pitch, which is exactly why they are worth probing for directly before you commit.