How to Choose a Partner for Enterprise Web App Modernization (Plus Five Firms Worth Shortlisting)

If you are about to buy a modernization programme, it is worth understanding that most of the outcome is determined in the eight or so weeks before anybody signs a contract.

By the time a vendor has been selected, the scope, the engagement model, the risk appetite, and usually the timetable as well have already been fixed by whoever wrote the first budget line, and the vendor simply inherits all of it. 

The public sector version of this problem is unusually well documented. In one recent government audit of the eleven federal systems judged most in need of modernization, the systems were found to range from about 23 to 60 years old and to cost approximately $754 million a year just to keep operating, and only three of the eleven had a fully documented modernization plan behind them.

Private companies do not usually publish figures of that kind, although the pattern we see in commercial buying processes is broadly the same. 

What follows is the evaluation sequence we would use, and after that a short list of firms that are worth a conversation.

Modernizing, rebuilding, or leaving the system alone

Three words tend to get used interchangeably in vendor conversations, and they describe three different purchases.

Migration means moving an application somewhere else without changing the way it works. Modernization means changing the architecture, the interfaces, or the data model while keeping the business logic that the system already encodes. A rebuild means discarding that logic and writing it again from a specification, which is only a safe thing to do if somebody in the organization can still produce the specification.

That last condition decides a great many projects, generally more than any argument about technology does. If the people who originally wrote the rules have left the company, and the rules now exist only inside the code, then what is being described as a rebuild is not really a rebuild. It is a reverse-engineering exercise with a delivery date attached to it, and reverse-engineering exercises are very difficult to estimate accurately.

There is also a reasonable case for doing nothing at all. If the application is scheduled for retirement within the next eighteen months, or it serves a few dozen internal users who have learned to tolerate it, or a funded package replacement is already in progress elsewhere in the organization, then modernizing it means spending capital on an asset that is about to be discarded. A vendor who points this out before you have paid them anything is telling you something useful about how they sell.

The six ways to move a legacy system, and when each one fits

The six-option framework is the common vocabulary in this market. A serious partner should be willing to argue for one specific option and to explain what that choice will cost you later on.

Refactoring is normally carried out incrementally rather than as a single cutover. The pattern that most teams use is a strangler approach, in which a routing layer is placed in front of the old system, one capability at a time is moved behind that routing layer, and traffic is switched over function by function until the old system has nothing left to do. It takes longer in calendar time, and it is considerably cheaper in failed cutovers, largely because no team is ever required to move everything over a single weekend.

Before arguing about which of the six options applies, it is worth deciding whether the application deserves the investment at all.

The federal rationalization playbook published by the US Chief Information Officers Council sets out a six-step process that scores every application on business value and on technical fit, and it names the awkward quadrant plainly:

applications with high business value and low technical fit are the “Refresh” candidates, meaning the ones that are worth spending money on, while low business value combined with low technical fit means “Remove”.

Running your own portfolio through that grid first will usually shorten the list of things you were about to modernize.

Sizing the risk before anyone quotes you a number

Vendors price the work they can see, and the risk generally lives in the parts they cannot see, so the buyer has to surface it first. There are five things worth measuring before the first proposal arrives.

The first is transaction volume, including the shape of the peaks. A system handling 5,000 transactions a day and a system handling five million are different engineering problems even when the code looks identical, and the second of the two cannot be tested properly in a laptop-sized environment.

Database age and dialect come next. A schema that has been in production for fifteen years will usually carry a good deal of logic inside stored procedures and triggers that nobody has read recently, so it is worth asking whether the vendor intends to move that logic up into the application tier, and what happens to it if they decide not to.

You should also count the integrations, which means every inbound and outbound interface, including the file drops and the scheduled jobs that no longer have an owner. In our experience the integration inventory turns out to be wrong on the first pass roughly as often as it turns out to be right.

Undocumented business rules are the fourth item. If nobody in the organization can point at a document, the assessment has to include a reverse-engineering activity, and that is something to be priced separately rather than absorbed into discovery for free.

The fifth is the compliance surface. Regulated data changes the testing burden, the hosting options, the number of people who have to approve a cutover, and which people at the vendor are permitted to touch the system at all.

Write these five items down and give the same sheet to every vendor. Where vendors give different answers to the same set of facts, that difference will tell you more about them than any capability deck is going to.

Engagement and cost models, and what each one hides

Three commercial structures dominate this market. Each of them is reasonable in the right situation, and each of them is regularly used in the wrong one.

Fixed bid works when the scope is genuinely closed, and somebody has already done the analysis. On a legacy programme, that condition is rarely true at the point of signature. A fixed price quoted before an assessment has been carried out is not really a lower price at all. It has either been padded to cover the unknowns, or it is a low number that the vendor expects to recover through change requests once the first surprise turns up in the database.

Time and materials fit discovery, reverse engineering, and any work whose shape is going to change as the team learns more. It transfers the risk to you, so it needs governance around it, which in practice means a fixed cadence, a burn report, and a named person with the authority to stop the work.

A dedicated team, which some firms sell as a pod, suits multi-year programmes where the same engineers need to stay with the system. It costs more per month than a project does, and less per unit of knowledge retained, and that trade-off is not something you will find written down in the proposal.

Published market bands for enterprise modernization work generally begin in the low six figures for a contained application and pass half a million dollars for a genuine enterprise rewrite, with timelines running from a few months up to about eighteen months. Those figures are orientation rather than a quote. The number that actually matters at this stage is the assessment fee, because the assessment fee is the only figure anybody can honestly commit to before the analysis exists.

Six checks that separate a modernization partner from a staffing vendor

1. They will sell you an assessment first, and they will price it separately from the delivery work.
2. The pattern they intend to use can be named, along with the conditions under which they would abandon it.
3. There are parts of the system they will tell you not to touch, and they will say which parts and why.
4. Intellectual property transfers to you on payment, in writing, with no licence carve-out left behind.
5. The engineers named in the proposal are employees rather than subcontractors assembled after signature. Ask directly, and also ask what happens if one of those engineers leaves.
6. There is a way out early, in the form of a paid trial period, a replacement guarantee for an engineer who is not working out, or a first phase that can be stopped without a penalty.

The sixth check is usually the most revealing one. A firm that builds risk reversal into its standard contract is telling you that it expects to be judged on the first ninety days of the engagement, and a firm that resists doing so is generally telling you that it does not.

Five firms worth putting on a shortlist

We built this shortlist from the vendors that recur across enterprise modernization comparisons, and then filtered on three things: verified client reviews rather than self-published awards, a stated modernization practice rather than general development work, and a published or otherwise discoverable commercial floor, so that you can tell early on whether you are the right size of buyer for them.

The ratings below are taken from Clutch and are quoted as published. Every entry uses the same fields, including the limitation.

1. CISIN (Cyber Infrastructure)

Fits when: you want a broad delivery bench and published price bands, and you are cost-sensitive without wanting an offshore body shop.

CISIN was founded in 2003, runs a thousand-plus engineering staff out of San Jose and a delivery centre in Indore, and treats legacy application modernization as a named service line rather than a by-product of general custom development. The published method begins with evaluation of the existing system and business-rules extraction before anything is moved, which is the sequence you want. Commercial terms are unusually explicit here, covering intellectual property transfer on payment, a two-week paid trial, a free engineer replacement, and in-house staff rather than contractors. Certification is CMMI Level 5 and ISO 27001.

Strongest at:

• Assessment and business-rules extraction ahead of migration or replatforming
• Mainframe and mid-tier re-hosting onto AWS, Azure, or Google Cloud
• Breadth across the surrounding stack, including data, integration, and security work

Rating: 4.9 out of 5 on Clutch from 36 reviews.

How they price: published hourly rates under $25 with a $5,000 project minimum, and service-page bands of $10,000 to $50,000 for a basic build, $50,000 to $200,000 for a mid-sized one, and $200,000 and above at enterprise scale.

Poor fit for: buyers who need a deeply documented, named case study in their exact vertical before signing. The public proof here leans towards scale figures, certifications, and review scores rather than published client outcomes, so the depth has to come out of reference calls instead of the website.

2. ScienceSoft

Fits when: the system is in healthcare or financial services and the audit trail matters more than the delivery speed.

ScienceSoft has been operating for more than thirty years, which is unusual in this category, and the age of the company does show up in the way it works. The firm leads with process and with documentation, and its modernization practice sits alongside a large testing and quality-assurance arm, so regulated buyers generally find that most of the paperwork already exists. There are around 750 experts, and the company is headquartered in McKinney, Texas.

Strongest at:

• Regulated-industry modernization with a compliance and testing wrapper
• Long-lived enterprise systems where stability matters more than novelty
• Small entry scopes, which makes a paid assessment easy to buy

Rating: 4.8 out of 5 on Clutch from 42 reviews.

How they price: $50 to $99 an hour, with a stated project minimum of $5,000.

Poor fit for: teams that want to move quickly and to iterate in public. The same process discipline that reassures a compliance officer is going to feel heavy to a product group that is used to shipping every week.

3. N-iX

Fits when: you are decomposing a large monolith and the data platform has to be rebuilt at the same time.

N-iX is the firm to call when the modernization is really a data problem that has arrived dressed as an application problem. The company runs a substantial data and analytics practice next to its engineering arm; it holds premier-tier partnerships with the major cloud and data platforms, and it works mostly with organizations that already have an internal engineering function of their own. It was founded in 2002 and is headquartered in Malmo, with delivery spread across Europe and the Americas.

Strongest at:

• Monolith-to-microservices decomposition on large codebases
• Data platform and analytics rebuilds executed alongside the application work
• Programmes that need several parallel teams rather than a single one

Rating: 4.8 out of 5 on Clutch from 35 reviews.

How they price: $50 to $99 an hour, with a project minimum of $100,000.

Poor fit for: anything that sits that six-figure floor below. A single contained application, or a scoping exercise on its own, will not clear the minimum, and there is not much point in starting a conversation that you are not in a position to fund.

4. Simform

Fits when: the work is mostly cloud migration and platform engineering, and the budget is real without being enormous.

Simform sits towards the lower end of the rate card, although the engineering itself does not sit at the lower end. The strength of the firm is cloud and DevOps work, which includes containerization, pipeline work, replatforming onto managed services, and the operational tooling that has to exist once the migration is finished. It was founded in 2010, it is headquartered in Orlando, and there is a large delivery organization behind it.

Strongest at:

• Rehost and replatform work with the DevOps tooling included
• Container and Kubernetes migrations
• Cost-conscious programmes that still need senior architecture input

Rating: 4.8 out of 5 on Clutch from 86 reviews.

How they price: $25 to $49 an hour, with a $25,000 project minimum.

Poor fit for: deep domain modernization, meaning the projects where the hard part is the business logic rather than the infrastructure. The centre of gravity here is the platform, and you should expect to staff the domain analysis yourself.

5. Intellectsoft

Fits when: you need a smaller and more attentive team, and the application has a significant front-end or mobile component.

Intellectsoft has the smallest bench on this list, at somewhere between fifty and two hundred and fifty people, and that is more or less the reason to consider the firm. A bench of that size means the senior people you meet during the pitch are more likely to be the same people who end up doing the work. The company has done a reasonable amount of enterprise front-end modernization, which is the kind of project where the back end stays largely intact and the interface layer is rebuilt around it. It was founded in 2007 and is headquartered in Miami.

Strongest at:

• Interface-layer modernization over systems that are not going to be rewritten
• Mobile and multi-channel extensions of existing enterprise applications
• Engagements where continuity of the same small team matters

Rating: 4.9 out of 5 on Clutch from 46 reviews.

How they price: $50 to $99 an hour, with a $50,000 project minimum.

Poor fit for: very large programmes running in parallel. A modernization that needs five teams working at once is going to strain a bench of this size, and you would find yourself competing internally for the same senior people who impressed you in the sales meeting.

The RFP, written out

A modernization RFP tends to fail for the same reason the projects do, which is that the requirements are vague, so every vendor ends up answering a slightly different question and the responses cannot be compared with each other. Research on project performance has put a number on the cost of this, and it found that nearly half of unsuccessful projects miss their goals because of inaccurate requirements management, at 47 percent. The remedy is unexciting, and it does work: ask everybody the same closed questions.

Use these nine sections. They are deliberately short.

1. Current state. Languages, frameworks, versions, hosting, database and version, daily and peak transaction volume, user counts by type, and the integration inventory.
2. What must not change. The business rules, the interfaces, and the reports that other teams depend on. Name them individually.
3. Target state. What you want to be true afterwards, expressed as capabilities and constraints rather than as technology names.
4. Constraints. Regulatory scope, data residency, acceptable downtime per cutover, and any frozen periods in your business calendar.
5. Approach. Ask each vendor to name which of the six options they recommend, and to explain why the other five are wrong for you.
6. Assessment. Ask for the assessment as a separately priced deliverable, with its duration, its outputs, and the names of the people who will do the work.
7. Team. Named roles, seniority, location, employment status, and the replacement process.
8. Commercials. The engagement model, the rate card, the change-control mechanism, and the intellectual property clause quoted in full.
9. Two references. Same industry or same technology, with permission to speak to them directly.

Ask for a fixed price on section six only, and leave everything else open until the assessment has been completed. If a vendor refuses to split the assessment out from the rest of the work, you can treat that refusal as the answer to the question.

Reading a case study without getting sold

Vendor case studies are written by marketing teams, and they are optimized around a percentage. Three questions will strip most of them down fairly quickly.

The first question is what the baseline was. A claim of forty percent faster does not mean anything without the starting figure and the measurement method, and if neither is present, the number should be treated as decoration.

The second is who actually did the work, and whether those people are still there. A case study written four years ago is describing a team that may no longer exist inside the company, so ask for the names and then ask whether the people with those names are still employed.

The third question is what went wrong. Every real programme has at least one bad month in it, and a partner who can describe theirs in specific terms, including what it cost and what was changed afterwards, is describing a real engagement rather than a brochure.

Reference calls are worth more than any of this. Ask the reference what they would do differently, and then pay attention to how long the pause is before they answer.

Running the selection from here

If you follow this order, the process generally takes around ten weeks rather than six months. Write the current-state pack first, because it is the artefact that every subsequent vendor conversation depends on. Send the same nine-section RFP to four or five firms and no more than that.

Buy a paid assessment from the two strongest responses, run the two assessments in parallel if the budget allows it, and then compare the two assessments rather than comparing the two proposals. After that, negotiate the delivery contract with whichever firm produced the assessment that showed you something you did not already know.

Sizing matters more than reputation at the shortlist stage. A firm with a $100,000 minimum and a firm with a $5,000 minimum are not competing for the same work, and putting both of them into the same process wastes everybody’s time.

If you are shortlisting for enterprise web app modernization on a mid-market budget, and you want a partner that publishes its price bands and its assessment sequence up front, CISIN runs legacy application modernization as a standing practice, beginning with system evaluation and business-rules extraction before any code is moved, for organizations whose aging applications have started to hold the business back.

Frequently asked questions

Should we modernize or rebuild? Rebuild only in the situation where somebody can still write the specification, either from memory or from documentation. If the business rules survive only inside the code, then modernize incrementally and extract the rules as you go, because a rebuild under those conditions is an estimate resting on unknowns.

Fixed bid or time and materials? Fixed bid for the assessment, because the assessment is bounded and reasonably well understood. Time and materials, or a dedicated team, for the delivery work, with governance attached to it. A fixed price for the whole programme signed before an assessment has happened is a price that you are going to end up renegotiating.

How long should the selection process take? Around eight to twelve weeks from the current-state pack through to a signed delivery contract, and most of that period is the paid assessment. Anything faster than that usually means the assessment was skipped, which does not remove the delay so much as move it into the middle of the project.

What does an enterprise modernization cost? Contained applications commonly land in the low six figures, and full enterprise programmes run past half a million dollars over twelve to eighteen months. The assessment itself is a much smaller commitment, and it is the only number that is worth fixing early.

How many vendors should we invite? Four or five for the RFP, two for a paid assessment, and one for delivery. Longer lists tend to produce more paperwork without producing a better decision, and they also burn the goodwill of the firms you did not choose.