How to Choose a Software Modernization Company

Buyers tend to put the wrong question to a software modernization company first. You will hear them ask some variation of can you rebuild this? The one that is worth asking, and the one that will actually protect your revenue, is which of this should not be rebuilt in the first place? A decent partner will have an answer for you before they put a number on the project. An inferior one will be eager to sell you a rewrite without so much as a glance at your batch jobs.

We put together this guide for the person with the hard choice to make. Perhaps you are a CTO or an operations lead, maybe a publisher with a CMS that has seen better days, or a business owner who has just been made aware that the platform is holding you back. In any case, you are about to put down some serious cash for a multi-year program. And if you believe the directional estimates, more than half of large modernization projects fail to deliver. Then there is the noise in the market: Research and Markets has the legacy software modernization category pegged at $17.57B for 2026 and climbing to $31.59B by 2030 (see their report here), so every sales deck is vying for attention and looking alike. Below you will find a short list of seven firms along with the red flags and questions that will tell you if you are dealing with a vendor or a true partner.

What a Modernization Partner Actually Does

There is a difference between migration and modernization. Migration is simply moving a workload. Modernization alters the operating model, behavior or architecture of it so the business can get on with things at a faster clip. You will see seven options in the category: rehost, replatform, refactor, rearchitect, rebuild, replace and retire. In practice, most programs will employ three or four of these across the same system.

The technology is seldom the difficult part. If you talk to primary sources and practitioners, they will cite the same risks time and again: data semantics that are not documented, external contracts you can’t unilaterally alter, engineers leaving with all the knowledge in their heads, and batch jobs with decades of reconciliation logic. A vendor who comes at you with microservices and Kubernetes before he has looked into any of that is merely selling a slide deck. We at Refact have made the point from the buyer’s perspective in our platform migration guide for founders: the tech is the last 20 per cent of the problem.

And while AI is set to change the cost curve in the next couple of years, with coding agents turning what would be an 18-month migration into a 4-6 week sprint in the right circumstances, do not be fooled. Those same people will tell you that without strong review pipelines, AI code is less secure and technical debt will pile up fast. It is an accelerator for a good program, not a replacement for one.

The Two Failure Patterns You Are Trying to Avoid

You are better off understanding the two types of failed modernization than committing a vendor’s capability matrix to memory.

Take the big-bang rewrite. The team sets out to supplant the old system with something new. After two or three years they have 60 or 70 per cent of the behavior covered. But the final 30 per cent is the odd core of the operation: regulatory quirks, edge cases, partner integrations. The costs go non-linear and you end up rolling back or running both in perpetuity.

Or there is the lift-and-shift that goes nowhere. You put the workloads in the cloud but do no architectural simplification. Run-costs may even go up. Now you have a monolith in IaaS with the same release cadence. Leadership will call it done and six months later the problems are back, only now with a hosting bill.

A top-tier partner will talk you out of either approach. They prefer to show you value in 3 to 6 month blocks rather than asking you to underwrite a five-year vision on faith. You will see them use incremental patterns like strangler fig replacements behind façade APIs or anti-corruption layers to modernize a single domain end-to-end.

1. Refact

For product leaders and operators who want a partner to think things through before code is written, Refact is the way to go. We are not in the business of enterprise transformation theater; we have a bias toward doing the work incrementally.

We have been at it for over 12 years and have shipped 200+ projects, with client relationships that average two years. Because our strategy, design, UX and engineering are all on the same team, you don’t get the handoff issues that open up the gap between plan and delivery.

Our best work has been in ecommerce and publishing. With Teton Gravity Research the story was moving 10,000 pieces from a failing ExpressionEngine install, but the real job was deciding what of the legacy system should not make it to the new one, such as user-generated content that had become an operational and legal headache. For St. Louis Magazine we got 30,000 articles off MetroPublisher without interrupting editorial workflows. These are modernizations, not redesigns, because we look at the content and operating model as the scope.

Then there is The Hustle. We put in place the Trends premium newsletter in a matter of two weeks by untangling a CMS, a payments stack and an email tool that had never been properly connected. It is the same pattern we see at scale in the enterprise.

Where Refact is the right call

• Before you scope a build, you need someone to tell you what to modernize and what to leave be. Real systems are a mess and so is ours: you have old plugins, custom code, a content model that has drifted over time and integrations with no clear owner. What you need is a strategy and execution in the same place, not some consultancy that will offload to an offshore build shop. You want a team of modest size but with skin in the game, one that will be around to answer for it after launch.

Refact is not the answer if you are looking to put hundreds of engineers on a bench for a global rollout or a 5,000-seat mainframe job. But most on this list don’t have that kind of problem. Their issue is a system that has insidiously become a business constraint and they want a partner who will be straight with them about it.

2. Thoughtworks

Then there is Thoughtworks. They are the firm to look at when the risk of modernization is operational and a misstep means regulator letters, compliance headaches or lost revenue. They have an engineering culture of uncommon discipline; their published work on the strangler fig pattern, evolutionary architecture and continuous delivery has in many ways set the standard for incremental modernization.

What you will find as a buyer is that they resist the rewrite-by-default approach. Expect to be put forward with phased work and safety nets you can measure. That suits a mission-critical estate well enough, but not an early-stage experiment. Be prepared for formal procurement and enterprise budgets; their senior team is not one to be trifled with.

3. Slalom

When your modernization is as much an organizational shift as a technical one, Slalom’s position between strategy and execution is handy. Their Zero Legacy angle is for those who already see the old stack for what it is and require executive buy-in for a multi-year plan.

You will see them do their best work in the public sector or regulated industries where data, ops and applications have to move in lockstep. They are not a scrappy build partner though. For a CMS replatform or a product rebuild, Slalom is more than you need.

4. Modus Create

Modus Create is for the business that cannot spare any downtime. Their approach to assessment-led, phased modernization is built on CI/CD discipline and the 7 Rs so teams can ship in small slices rather than make a bet on a cutover. If your customer transactions or workflows are regulated, they are a sensible choice. The trade-off is scale. A mid-market or enterprise program will fit in fine, but if you have to rationalize 50 systems across three continents you would be better off with a larger outfit.

5. EPAM

If you want scale, EPAM is the play. We are talking large application estates and programs that go on well past the first release. They put migration delivery together with SRE, containerization and testing automation. It is important because too many firms budget for the move and forget the two years that follow.

They are right for you if you need engineering depth and post-launch support. Not so much if you want a small team in the room with you every week. There is process to a large delivery organization like EPAM and it can feel formal when you want to get at senior judgment directly. You will find the same with most in this tier, which is why we advocate for staged commitments in our cloud migration consulting overview rather than signing a master services agreement on day one.

6. Astadia (part of Amdocs)

For a mainframe-heavy operation, Astadia is the specialist. If you are still running COBOL, Unisys or IDMS, a generalist studio is not going to cut it. You need people who have read PL/I in production and the tooling to back it up.

Astadia has the narrowness to be of value here. They will not be of use in redesigning your customer experience, but they will get you off the mainframe with the behavior intact, which is a job in itself.

7. TSRI

TSRI gets at the part of modernization that gives people pause: the old codebases in languages the original authors are long gone from, where you run the risk of mangling the business logic. With deterministic transformation in 35-plus languages and UML documentation to explain what the code can no longer tell you, they are very useful in high-risk legacy environments like the public sector.

It is not a full program by itself. Put them to work alongside a partner who can own the product and architecture side and you have a much better chance of landing it.

How These Seven Compare

Firm	Best fit	Engagement shape	Watch out for
Refact	Operators and product leaders who need strategy and execution from one team; CMS, ecommerce, publishing, SaaS, AI features, migrations	Small cross-functional team, discovery-first, often a 12 to 24 month relationship	Not built for thousand-seat mainframe programs
Thoughtworks	Regulated enterprises and mission-critical legacy where rewrite risk is high	Senior engineering teams, incremental delivery, enterprise procurement	Enterprise budgets and longer buying cycles
Slalom	Public sector, healthcare, finance; programs needing executive alignment alongside delivery	Consulting-led, governance heavy, U.S. footprint	Too heavy for a focused product rebuild
Modus Create	Mid-market to enterprise teams needing low-disruption, phased modernization	Assessment-led, 7 Rs methodology, strong CI/CD discipline	Less suited to the very largest global rollouts
EPAM	Large application portfolios needing scale, tooling, and post-launch operations	Migration factories, SRE, managed services, global bench	Process weight; less founder-style intimacy
Astadia	Mainframe migrations off COBOL, Unisys, Adabas/Natural, IDMS	Specialist migration factory, automated conversion and testing	Narrow scope; not a product or UX partner
TSRI	High-risk code transformation, legacy documentation rescue	Automated transformation across 35+ languages, plug-in to larger programs	Needs a partner that owns architecture and product decisions

The Five Questions That Decide the Hire

Don’t let a capability matrix be your guide in vendor selection. The answers to questions the sales team hasn’t had time to rehearse are far more telling. Five of them will do most of the work.

What should we leave alone? See if they will name the systems they would not put a hand to for the next year. A weak partner will scope it all since it is billable. A good one has the strategic sense to say not yet.

What’s your incremental plan for the opening 90 days? Put them to the test and ask for a side-by-side of an incremental approach as against a rewrite. Firms that mean business with incremental work will have a straight answer; those that don’t will try to put you in a discovery workshop.

How do you see the business carrying on through cutover? You want to hear specifics: golden master testing, shadow reads, canary deployments, feature flags, dark launches and the like, along with rehearsed go/no-go criteria. If they are talking about a weekend deployment, I would slow down.

Who is on the team? Can we sit down with the delivery engineers? Vendors have a habit of putting senior architects in front of you during the sale and junior offshore developers in for the actual delivery. Don’t let it happen. Make sure you meet the ones who will be writing the code and owning the data.

And how is knowledge going to be handed over to us? There is no point in modernizing if you end up more at the vendor’s mercy than you were before. A good partner will coach your people and produce documentation you can actually use so you can stand on your own two feet when the engagement is done.

Red Flags Worth Walking Away From

You can read enough of these discussions on Reddit, X or Hacker News to spot some hard signals.

If their default is to recommend a rewrite to microservices on Kubernetes without regard for the problem at hand, they have one solution and are in need of a project to suit it. Microservices are a means to an end. For most teams it is wiser to modularize the monolith first and build the operational maturity you need.

Then there are the pre-baked roadmaps you get in week one. Be wary. A proper assessment requires weeks of engineer time for dependency analysis and log-based criticality work. If they have a polished roadmap by day five they wrote it before they met you.

Data migration and integrations being lumped into a single line item is another way projects fail. In practice, the data work is half the cost. Our data migration practice at Refact is there for the same reason our case studies show more time spent on data than UI: this is where things have a way of quietly dying.

And watch for the long-tail red flag of lock-in via custom frameworks or an unwillingness to document their architectural thinking. It doesn’t show up in the signature but it will be obvious in three years.

When Not to Modernize

The best answer in some cases is not yet. If you have a stable system with few incidents and clear ownership, you may not have a need to modernize. The constraint could be the approval process or a single integration and swapping out the platform won’t remedy that.

Or consider a system rife with undocumented behavior and regression risk. If the partner can’t tell you how they will preserve it, then you should be investing in observability and testing first to make the system legible. An independent assessment or fractional CTO can be of help making that call, which is why we put together a fractional CTO services guide.

Choosing the Right Partner for the Shape of the Problem

To be frank, there is no firm on this list that is right for every situation. You have to match the partner to the constraint.

Go with Refact if you want a single accountable team for strategy and execution and you have the kind of mess real businesses do, and you want your answers before building starts. If the program is broad and the governance load is real, with an enterprise stakeholder map, look at Thoughtworks, Slalom or EPAM. For a phased modernization where you need to keep operations steady, Modus Create is the choice. And for a true legacy conversion on mainframes or in code your current engineers can’t safely read, you want Astadia or TSRI.

But what the top programs have in common has little to do with the vendor. They back every increment with a tangible business result and put the money into dependency mapping and testing before they touch any code. They keep the architectural decisions in-house and treat modernization as a product effort, not a project with an expiration date. The right partner facilitates that; the wrong one makes it a non-starter.

Still on the fence about whether to rebuild or migrate? Refact’s discovery process is designed to settle the matter before a line of code is written. That is where you will save the most time and pain.