Choosing a partner for an aging application comes down to risk more than technology, and evaluating app modernization services well starts with that idea. Your current system still earns revenue, so any plan that interrupts it carries a real price. The partner you pick decides how much of that risk lands on your side of the table. This guide shows you how to compare proposals on evidence rather than on polish.
You do not need to follow the engineering. You need to know which questions expose a weak plan, which numbers to ask for, and what a sensible first milestone looks like. Along the way you will see how one published case set a two-year rewrite quote against incremental delivery. You will also see why the quietest part of the project, understanding what the old system does, often decides the outcome.
Providers bundle the same activities under different names: assessment, re-architecting, migration, containerization, refactoring, interface redesign and integration. Itransition, for example, lists most of these as separate offerings on its legacy modernization page. The labels matter less than one underlying question. How much of your existing system do you keep, and how much do you replace?
McKinsey describes technology modernization as transforming existing applications to take advantage of modern technologies and frameworks. That definition is broad, so two quotes for modernization can describe entirely different projects. One vendor may move your application to new hosting, while another rebuilds it from scratch. You end up comparing unlike things under a single label.
Before you request proposals, pick the outcome you care about most: lower running cost, faster change or lower operational risk. Each one points to a different scope. If you are unsure whether your system counts as legacy at all, our guide to what a legacy software system is helps you place it.
A vendor can only be as good as the problem you hand over. "Our software is old" is not a brief. "Releases take months and every outage costs us orders" is one, because it gives a partner something to measure against.
Thoughtworks describes a useful order of work in its writing on legacy displacement. First understand the outcomes you want, then decide how to break the problem into smaller parts, then deliver those parts, and finally change the organization so the pattern continues. Its authors warn that jumping to the delivery step without the first two is a recipe for failure.
Strong proposals answer specific questions without being asked twice. Use the four below in your proposal review and in the follow-up call. The content of the answers matters, but so does how directly the partner gives them.
Ask for a date. A plan that shows no production value until a final cutover concentrates all your risk into one launch window. Prefer proposals that ship in slices, each with its own rollback path. If a partner cannot name a first slice, they have not yet understood your system.
Request two or three measures. Cycle time, meaning how long a change takes from request to tested release, is a good one because it shows whether the work lowers the risk of change. Incident counts and time to restore service show resilience. Agree on baselines now, since nobody can prove an improvement against a number no one recorded.
Old and new code will run side by side for months, and most surprises happen at the seams. Ask who writes and maintains the tests there, and who pays for them. In the Thoughtworks case, the legacy team had no capacity to learn a new category of contract test, so the new team wrote them all during the trial. That worked, but someone had to plan for the cost.
Login sessions, customer records and payment details cross boundaries during a gradual migration. Thoughtworks describes saving authentication data in the iOS Keychain and Android EncryptedSharedPreferences, so users stayed signed in across old and new screens. You do not need to judge that detail. You need a partner who can explain their own version in plain terms. If you serve EU customers, ask how GDPR duties are handled and confirm the answer with your legal adviser.
Most proposals describe the new system at length and the old one in a single paragraph. That is backwards. The riskiest assumption in any modernization is that someone understands what the current system does, including the rules nobody wrote down.
The InfoQ article on AI interventions in legacy modernization, written by engineers at Stride, calls this the concept recovery problem. Legacy systems stay in use because the business depends on them, yet fewer engineers know how they work. Over time the software and the business drift apart, and staff compensate with workarounds. Without recovery, the authors warn, a business risks a failed modernization or losing customers who rely on functionality nobody considered.
Their example is simple. A company sells to retail customers, then adds a wholesale unit with its own discounting and billing rules. If the wholesale features were built on the retail implementation, the software never models the independence of the two units. A rewrite that copies the code faithfully also copies that confusion.
Ask which documents you receive before building starts. A good answer includes a written description of business rules, calculations and data handling. It also includes a map of the screens and journeys involved, plus a list of the database tables and processes each feature touches. Your operations lead should be able to read these, not only engineers, and they become your acceptance criteria later.
Stride's authors report that architects they worked with spent a week or more following references through code to build up knowledge. A systematic trace of the same code took minutes. That is one team's report on its own tooling, not a benchmark. It does show why you should ask each partner how they investigate, instead of accepting a fixed discovery duration.
Thoughtworks documents a trial on a large retail mobile app in its article on using the Strangler Fig pattern with mobile apps. The client had been quoted around two years for a full rewrite and worried about the reception of a big-bang release among millions of customers. So the team embedded new, modular parts inside the existing app and replaced one domain at a time.
The figures deserve a careful read, because they show what incremental delivery does and does not promise.
| Measure | Legacy or rewrite path | Incremental trial |
|---|---|---|
| Time to first value | Around two years, quoted for a full rewrite | 1 month, because both modules already existed; 4 months from a blank page |
| Median cycle time over 30 days | 20 days (legacy app) | 9 days and 10 days (two micro-apps) |
| Scope delivered | The entire application at once | Two domains out of many |
| Source: Thoughtworks proof of concept |
Thoughtworks is candid about the limits. The work was a proof of concept covering two domains. The authors say they would want data on time to restore service and outage counts before recommending the approach broadly, and they note it is unclear how complexity grows as more domains join. Treat the numbers as an illustration of a mechanism, not a forecast for your project.
The article also accepts a larger temporary overhead, because old and new systems run together. For you, that means the incremental route can cost more in coordination even while it lowers risk. If a partner proposes it, ask them to show that overhead in the estimate.
Thoughtworks notes that a complex, high-availability system may demand a more incremental approach than a simpler, less critical one. The reverse also holds. A small application with well-understood requirements and low outage cost can reasonably be rebuilt in one go. The decision depends on how much a failed launch would cost you, not on which approach is fashionable.
Expect every vendor to mention AI. Ask where in the process they use it, because the answer separates real tooling from marketing. The InfoQ authors argue that most commercial AI tools target code generation, which they call accidental complexity. In their view the harder bottleneck is working out what the software should do.
Their method uses static analysis to gather the relevant code and database context, then asks language models to draft business requirements from it. They stress that human experts must still adapt and verify the output. So ask who reviews the AI-drafted requirements, and whether your own staff confirm them. A document nobody on your side has read is a liability, not an asset.
The authors also note that some of these processes grow expensive as the amount of code increases. Ask whether AI usage costs sit inside the estimate or arrive later as extras. If you plan to connect AI features to the modernized system, our guide to connecting AI to your business infrastructure covers the groundwork.
For workflow-centric tools such as approval chains and internal forms, Gartner's research on AI-augmented low-code platforms describes a practical path to modernization by reusing current platforms and teams. Such platforms fit workflow-heavy tools better than products with intricate, customer-facing logic. Ask your partner to explain which category your system falls into and why.
The table below is a general orientation, not a quote. Costs and suitability vary by system, so have an independent technical adviser review any plan before you commit, and ask each vendor to price the same scope.
| Route | What changes | Usually fits | Main trade-off |
|---|---|---|---|
| Migrate to new hosting | Infrastructure moves; code largely stays | Stable application whose main issue is the platform | Limits of the old code remain |
| Refactor | Internal structure improves; behavior stays | Valuable application that is hard to change | Needs solid discovery and test coverage |
| Incremental replacement | Modules are replaced one at a time | Critical systems that cannot risk a big-bang launch | Running old and new together adds overhead |
| Full rebuild | A new system replaces the old | Small or well-understood systems | Longest wait for value and the largest cutover risk |
| Low-code on a current platform | Workflows move to an existing platform | Workflow-centric tools | Limits on complex, customer-facing logic |
A good partner often proposes a mix. Ask them to explain why each part of your system gets its route, and which parts they would leave alone for now. Leaving a stable component untouched is often the cheapest decision in the whole project.
Structure the contract so each milestone ends with something running in production or a document you can verify. Tie payments to those outcomes instead of calendar dates. Include the agreed baselines, such as cycle time, so acceptance has an objective test.
Keep a way out. Thoughtworks used the feature flags of an experimentation tool to switch the new experience off without a release, which shortened recovery time if an outage occurred. Ask your partner whether every slice has a rollback path, and have them demonstrate it before launch.
Settle the ownership of knowledge as well. Documentation, test suites and the recovered business rules should belong to you at the end. An independent studio offering Xerx custom software and web app development, or any other partner, should be willing to put those terms in writing.
Treat any guarantee with suspicion. Old systems hide unknowns, so an honest partner states assumptions and explains how surprises will be handled instead of promising a fixed outcome.
A modernization plan is only as strong as its first slice in production.
Take these questions to your next vendor call, starting with the first: on what date does a real user touch something new? If the answer is "at launch", you have learned what you needed to know.
There is no universal answer, because it depends on the system and the route. In the Thoughtworks case, the client was quoted around two years for a full rewrite, while the incremental trial would reach first value in about four months from a blank page. Ask each partner for dated slices instead of a single end date.
Not necessarily. Thoughtworks accepts a larger temporary overhead because old and new systems run together. The approach tends to lower risk for complex, critical systems, while a simpler, less critical application may suit a rebuild.
AI can speed up parts of discovery, such as drafting business requirements from code, according to the InfoQ authors. They still require human experts to adapt and verify the output, so your own staff should review what it produces.
At minimum, a readable description of business rules, calculations and data handling, a map of the affected user journeys, and a list of the database tables and processes involved. These documents should also serve as your acceptance criteria.
For workflow-centric tools it can be. Gartner describes AI-augmented low-code platforms as a practical path when you can reuse current platforms and teams. Products with intricate, customer-facing logic usually need a closer review before you choose this route.
Keep reading
A quote for a headless shop looks larger than the platform price suggests. Here is where the money goes, what founders underestimate, and when the spend pays back.
Before you budget for a shared connection layer, learn what it does, when a few direct connections are enough, and who owns the risk after launch.
Age does not make software legacy. Learn the cost-of-change test, six warning signs, four modernization routes and the data risks to weigh before you set a budget.
