How to Choose a Legacy Software Modernization Company (+10 Questions That Expose the Wrong Vendor)
Published: – Updated:
When problems arise in a modernization project, the warning signs usually trace back to the proposal from your legacy software modernization company. When you double-check it, you’ll probably find a vague plan without clear milestones.
We’ve seen it when clients turned to us in the middle of a modernization project they started with another vendor. They were paying money but couldn’t understand what it was for or at what point the project was supposed to end.
Pick a legacy software modernization company that plans the same way, and you’ll pay for a new system while you keep running the old one for a very, very long time. That’s why we wrote this guide — to help you avoid such situation. It will be useful for CTOs and IT leaders who are shortlisting legacy software modernization companies.
What separates a software modernization company from a general development agency?
Modernizing old software and building new software are two different jobs. A new product starts from a blank page. A modernization project starts inside a system that’s already running, often with thousands of people depending on it or little to no documentation.
Many companies offer both, so when it comes to modernization, pay attention to what the potential vendor asks about your existing system. Partners with real experience in application modernization consulting services ask first and pitch tech stack later. They want to know what the system does, who depends on it, the governance context, and which parts can never go down. Beyond that, look for the following qualities:
- Fluency in old and new stacks. The team must read the old code while building the new system. A vendor that’s strong in React but can’t work with 15-year-old Java or PHP will struggle to find the business rules buried in that code.
- Phased delivery. Legacy software modernization services should default to step-by-step releases for large systems that can’t go offline for long. We suggest a full rewrite only as an exception, when there are solid reasons for it, and never as a routine method.
- Safe releases. Before talking about the target architecture, the vendor should explain how production stays safe during every release, including a rollback path for each one.
- Support after cutover. A cutover doesn’t mean the work is done. Someone still has to retire the old components, fix bugs that surface in production, and hand knowledge over to your in-house team.
To make sure you haven’t missed anything, bring the person who has kept the system running for years to the first call. In our experience, that is the most useful thing a client can do. That engineer knows which job must never fail and which fix from a decade ago is still holding everything together. Documentation shows what the system was designed to do, but that person knows how it actually works and where it relies on unusual or temporary solutions.
Why prepare a system brief for calls with vendors
A system brief is a one- or two-page document that allows you to stay confident during your first calls. It enlists all the important details you will (or, at least, should be) asked about. It’s also the basis for your questions.
When we — a modernization company — get it, the first and the final estimates are usually very close. We can also prepare a recommendation much faster, since discovery focuses on the risky parts of the system, instead of mapping the basics.
A good system brief covers the following things:
- System role and dependencies: The list of the main functions, the user groups, and every system that is connected to it. The integration list is very important; if you miss it, you can give us the wrong picture of the system’s complexity.
- Critical uptime requirements: Peak periods, uptime commitments, and regulatory deadlines. These shape the release plan more than any technology choice.
- The definition of “done”: Name the components you expect to retire and the person inside your company who signs off on switching the old system off.
- Shareable information: Code access, architecture documents, and time with the people who run the system. The more a vendor sees, the more valuable their recommendations will be.
- Key constraints: Budget range, target dates, and work your own team will handle. That last point decides on the engagement model.
6 criteria to look for in legacy software modernization services
1. Technical approach
Which modernization strategy the vendor would use and why. If a vendor leans toward a single cutover, they should defend that choice with clear, sensible arguments. Our Strangler Fig vs. Big Bang comparison shows how to tell the two cases apart.
2. Risk control
This is where weak vendors get vague. Ask how they’ll roll back each release and rehearse the data migration, and what test coverage they’ll build before touching old code. Then ask what they did when a release went wrong on a past modernization project. Expect clear answers and, ideally, examples.
3. References and proof
Ask for examples of modernization work. Before-and-after numbers (load times, incident rates, release frequency) are a big plus.
If there are no figures, that doesn’t automatically mean the vendor lacks experience. Modernization work is often under an NDA, so they may only share part of it. Instead of ruling that vendor out, ask for as much detail as they are allowed to give.
Before you modernize, know where you stand.
4. Team composition
You need to know who will work on your project, by name and by role. That usually means people who understand the legacy stack and the target architecture, plus an architect. The latter stays involved for the whole program. Before signing, ask to meet the team and use the call to see who will actually do the work.
5. Pricing transparency
A credible quote includes separate lines for discovery, architecture, development, testing, and knowledge transfer. With a single total with no breakdown, you can’t compare vendors or see what’s missing.
6. Engagement model
The engagement model you choose for legacy application modernization services defines roles and responsibilities. Pick the model that matches your internal capacity and your timeline. Common options include:
- Consulting: Through application modernization consulting services, the vendor runs the assessment and roadmap, and your team builds.
- Dedicated team: The vendor’s engineers work as an extension of your team for the full program.
- Fixed-scope phases: Each phase is scoped and priced separately after discovery.
10 questions to separate right and wrong vendors
Questions about strategy and track record
1. What would you need to assess before recommending a strategy?
Good answer: “Code access, your architecture docs, and a few sessions with the people who support the system. Then we’ll recommend a strategy for your case and explain the trade-offs.”
Red flag: “From what you’ve described, we’d rebuild it as microservices.”
2. Can you share a legacy system modernization case study with before-and-after numbers?
Good answer: “Here’s a system similar to yours in size and stack. You’ll see load times, incident counts, and release frequency before and after.” Or: “We can’t name this client, but we can walk you through the process, the changes, and the results we’re allowed to share under the NDA. We’ll also explain how we’d apply that experience to your project.”
Red flag: “We delivered a modern, scalable platform, and the client was very happy with our work.”
3. Tell us about a modernization project that didn’t go to plan.
Good answer: “On one project, the data migration took twice as long as planned because we underestimated the data volume. Since then, we rehearse every migration on a full copy of production data.”
Red flag: “That couldn’t happen. Our projects always go to plan.”
Questions about planning
4. What are the milestones and the work in each phase? When does the legacy system get retired?
Good answer: “Each phase has a date and a defined scope. The roadmap ends with a target date for switching off the old system.”
Red flag: “We’ll know more once we start.”
Questions related to the system failures
5. How will you find business rules that aren’t documented?
Good answer: “Before making any changes, we write tests that record what the system does today. We also trace the code and interview the people who use it.”
Red flag: “Our developers are experienced. They’ll pick it up as they go.”
6. How do you keep the old and new systems in sync during the transition?
Good answer: “Each data set has one source of truth until the switch. Automated checks catch mismatches before users see them.”
Red flag: “We’ll move all the data at the end.”
7. What’s your rollback plan if a release breaks production?
Good answer: “If the release fails, traffic goes back to the old component, which stays in place until the new one proves itself.”
Red flag: “We test thoroughly, so a rollback plan won’t be needed.”
Questions about team composition, price, and knowledge handover
8. Who exactly will be on our team, and who stays for the full program?
Good answer: “Here are the architect and tech leads. The architect stays for the whole program, and any team change would need your sign-off.”
Red flag: “We’ll assign the team once we’ve signed the contract.”
9. What’s in your quote, line by line, and what’s not there?
Good answer: “Discovery, architecture, development, testing, and knowledge transfer are priced separately. If there are exclusions, they are listed in writing.”
Red flag: “It’s one fixed total, and everything’s included.”
10. How will knowledge move to our team, and what happens if we part ways?
Good answer: “You own the repositories and the pipeline from the start. Documentation is one of the deliverables, and your engineers join our code reviews.”
Red flag: “We host and manage everything on our side, so you don’t have to worry about it.”
Comparing legacy software modernization companies side by side
Nothing is more prominent than numbers. Use the matrix below after your vendor calls to define the strongest fit and defend your choice to the board.
Score each vendor from 1 to 5 on every criterion (5 is the highest), multiply by the weight, and add up the results. The maximum is 5.0. Vendor A (example) scores 4 on technical approach, which carries a 20% weight, so that row gives 4 × 0.20 = 0.80. Repeat for every row and add the results to get the weighted total.
We recommend getting at least two people to score vendors separately. If you get wide gaps between scorers, you need another call. It’s also better to fill the scorecard right away after the meeting, because answers blur easily once you’ve spoken to several vendors.
Adjust the weights to your situation. If your team will do most of the build, raise the engagement model. For a regulated or always-on system, raise risk control. A score below 3 on risk control is a deal-breaker for any industry, even when the total is high.
Aimprosoft’s long-term modernization projects
Aimprosoft has worked on Motive Retail’s platform for more than 17 years. The work started with a desktop certification app and a Liferay-based portal that had become hard to maintain and couldn’t scale.
The team rewrote the certification system as a standalone service and turned the portal into a central integration hub. The stack was upgraded in steps, from Liferay to Java, from JavaScript to TypeScript, and through several Angular versions. Live operations continued all this time.
The same pattern shows up in Aimprosoft’s partnership with Crop Trust. The Genesys platform moved from legacy PHP to Java and React over a decade of incremental delivery. It now hosts more than 4.3 million seed samples from 450+ genebanks in 100+ countries.
Both systems kept working for their users while the stack changed underneath, and each step was small enough to test on its own. See how our legacy application modernization services keep systems like these running while they change.
Mistakes that lead to the wrong modernization vendor
It looks easy to compare vendors based on pricing or a proposed architecture. But neither tells you much about how well they understand your system, governance, or business goals. Or what engagement model they suggest. Or how they manage risks.
An impressive target architecture says little about what happens while you’re replacing legacy systems: how the team will test the new system, migrate the data, keep the old system running, or roll back if something goes wrong. The lowest price quote can be just as misleading, especially one prepared before the system review.
To make sure vendors are pricing the same work, ask for a proper discovery phase before comparing quotes, review the risks and assumptions in each proposal, and break down the pricing far enough to see what is included and what is not. Then use the scorecard to compare the legacy software modernization companies on your shortlist.
This way, you can find a modernization partner who helps make your business scalable and future-ready while keeping it stable.
New to the topic? Our plain-English guide explains what application modernization involves.
Shortlisting modernization vendors? We offer an assessment to review your architecture and recommend the strategy.
FAQ
How do I evaluate a legacy software modernization company?
Score each vendor on six criteria: technical approach, risk control, references, team composition, pricing transparency, and engagement model. Weight risk control and proof highest. Compare legacy software modernization companies side by side on a scorecard, and rule out any vendor that can’t explain how production stays safe during each release.
What should I ask a legacy modernization vendor before signing?
Ask for the milestones and the work planned in each phase. Then ask when the legacy system gets retired. Also request a case study or a detailed walkthrough of similar work, a rollback plan, the named team, and a line-item quote. A legacy software modernization firm that offers legacy application modernization services should answer all of these without hesitation.
Should I pay for a discovery phase before choosing a vendor?
Yes, for any system larger than a single module. A paid discovery phase is the most reliable way to see how a vendor works on your actual code before you commit to the full program. Make sure the contract states that you keep the assessment and roadmap, so you can take them to another vendor if needed.
How do modernization consulting firms typically structure their engagements?
Most start with an assessment of the current system, followed by a roadmap and phased delivery. Firms offering application modernization consulting services usually support three models: consulting only, a dedicated team, or fixed-scope phases priced after discovery. The right model depends on how much of the build your own team can take on.
What’s the difference between a modernization vendor and a system integrator?
A system integrator connects and configures existing systems, often packaged software like ERP or CRM platforms. A software modernization company changes the legacy application itself, including its code, architecture, and data. Some firms do both. When comparing legacy software modernization services, check how much of each vendor’s past work involved rebuilding old code.
How many references or case studies should a vendor be able to provide?
Ask for at least two or three legacy system modernization case studies, ideally with before-and-after numbers. At least one should involve a system close to yours in size or stack. Modernization work is often covered by NDAs, so a vendor may not be able to name clients or share every figure. In that case, ask for a detailed walkthrough of the process, the challenges, and the results they’re allowed to share.
How long does a typical legacy modernization engagement last?
It depends on scope. A single module usually takes a few months. Several connected systems take several months to a year and are delivered in phases. A core platform often becomes an ongoing program that improves with each release.
