What does it cost to rebuild a line-of-business application? Half of our first calls open with that question. Search for legacy application modernization cost and you get maturity models and almost no arithmetic. The strategy posts explain how to carve up an old system. They stop one page short of the price.
We wrote that page for our own quotations. We migrated the CRM of a real estate group: live data, moved without stopping the business, billed against our public day rates of 150 to 450 EUR. Out of that work came a simple way to compute legacy application modernization cost. Four blocks of days, one multiplier table, nothing else.
Here is the whole method, numbers included.
Keep, wrap, or rebuild
The price starts with a decision that is never made globally. It is made module by module, after an audit.
- Keep. The module does its job and nobody complains. Leave it alone and document it. Cost: a few audit days.
- Wrap. The service is still useful but the code is untouchable. Put an API in front of it, make the rest of the system talk to that API, and replace the inside later, under control. That is the heart of the strangler fig.
- Rebuild. The module blocks the business or sits on a dead technical base. Rewrite it.
The split across those three columns moves the budget far more than any framework choice. In a ten-year-old system, genuine rebuild candidates rarely make up more than a third of the modules. Quoting a full rewrite before doing that sort means charging you double.
Data migration sets the budget floor
New code is the predictable part of the project. A team that has shipped before can estimate a management module, a rules engine, a synchronization job. Data cannot be estimated from a distance.
Years of customer history. Duplicates created by three generations of sales people. Free-text fields hijacked to store dates. Business rules that exist nowhere except in data-entry habits. On the real estate group's CRM migration, most of the effort went into cleaning, mapping and reconciliation testing, and the source system stayed in production from the first day to the last, without the business stopping once.
Rebuilds rarely fail on the new code. They fail on the data.
That is why the migration sets the budget floor. You can shrink the functional scope, simplify screens, push a module to next quarter. You cannot migrate 80 percent of a customer record.
Legacy application modernization cost, in four blocks of days
We price every rebuild in four blocks, each expressed in days.
- Audit days. Read the code, map the data, interview the users, sort every module: keep, wrap or rebuild. Plan for 5 to 10 days.
- Migration days. Write the scripts, clean, map, replay the migration on copies, chase the reconciliation gap down to zero.
- Rebuild days. Build the modules marked for rebuild, plus the APIs in front of the wrapped ones.
- Cutover days. The cutover itself, the parallel run, the rollback plan.
A realistic mid-size CRM example at our public rates: 8 audit days at 400 EUR is 3,200 EUR. 25 migration days at 300 EUR is 7,500 EUR. 60 rebuild days at 300 EUR is 18,000 EUR. 6 cutover days at 450 EUR is 2,700 EUR. Total: 31,400 EUR.
On a larger scope, the same arithmetic becomes a dedicated pod at 15,000 to 40,000 EUR per month. The rates hold because of our hybrid model: steering, quality and contracts in Belgium, an engineering center in Rabat.
The multiplier table
The base calculation assumes normal terrain. Here is what multiplies it, observed on our own delivered projects.
- No reliable unique key in the source data: migration days x2.
- Undocumented business rules carried by one person: audit days x2.
- Cutover required with zero downtime: cutover days x2.
- Live third-party integrations such as accounting, payroll or external portals: add 30 to 50 percent to the rebuild.
And here is what multiplies nothing, whatever gets said in meetings: the number of screens, the language of the new system, the framework debate. Those discussions fill whole afternoons and barely move the budget.
What leaving the old system really costs
The rebuild quote does not cover everything. Three items stay on your side and deserve a line in your own spreadsheet.
Licences and contracts first. The old vendor usually holds you to a termination notice period, and the maintenance contract keeps running through the parallel run. You will pay for two systems for a few months. That is normal, as long as it was written down before signing.
Knowledge second. Someone has been keeping the old system alive for years, often a single person. Their days during the audit and the migration are the scarcest resource in the project. Book them early, formally, with their manager.
Red flags in a modernization quote
A quote that hides the migration risk is easy to spot.
- Data migration is one line: included.
- The fixed price was set before anyone saw real data.
- Neither the cutover nor a rollback plan is mentioned.
- The schedule has no parallel run.
- Days per profile are missing, only a total.
None of these proves the vendor is incompetent. Each one proves the migration risk has been moved from their side of the table to yours, without anyone saying so.
Where this method stops
Two limits, in the interest of honesty. Before the audit, every figure is a range; the multipliers above come from our 17+ shipped projects and they are observations, not laws. And the method prices the build and the migration, nothing more. Change management, training and the product decisions the rebuild will surface are not in it. Those costs are real, and they are yours.
If you want a number for your own scope instead of a slide deck, describe your system at jadev-corp.com/quote. You get a formal quotation reviewed by an engineer within one business day, and the earliest a project can start is two weeks after the request.