Build or buy: the honest case for each in legacy application modernization services
Should you build or buy when modernising a legacy application?
Buy when the process your legacy system encodes is ordinary and you are willing to change it to match a product. Build when that process is how you compete or how you are regulated. Most legacy application modernization services programmes end up as both: a bought core with custom surfaces around it.
Buy when the process your legacy system encodes is ordinary and you are genuinely willing to change how you work to match a product. Build when that process is how you compete, how you are regulated, or how your data is shaped. Most legacy application modernization services programmes end up somewhere in between: a bought core for the commodity parts and custom surfaces around the two or three things that are actually yours.
This article gives you a five-question test that produces a defensible answer, a side-by-side of what each route costs in money, time and control, and the part nobody calculates until it is too late, which is what it costs to reverse the decision.
What buying and building mean in a modernisation
Buying means adopting a commercial product and configuring it: an ERP, a CRM, a core banking suite, a hospital information system, a warehouse management platform. You get a data model, a process model and a release cadence you do not control. You migrate your data into their shape, you retrain your people to their workflow, and you pay a licence for as long as you use it. The implementation, not the licence, is usually the larger number.
Building means writing software that fits your process. You own the data model, the code, the release cadence and the dependency risk. You carry the cost of building things the product would have given you free, such as user management, reporting and audit logging, and you carry the responsibility for keeping it alive for a decade.
The third option, which we recommend more often than either, is to keep the legacy system's core running while replacing capability around it. An anti-corruption layer holds the old data model at arm's length, an API layer exposes what the rest of the business needs, and new modules are built or bought one at a time. This is the strangler-fig approach, and it converts a single irreversible decision into a series of small, reversible ones.
Where each route wins
| Dimension | Buy a platform | Build custom | Hybrid: bought core, custom edges |
|---|---|---|---|
| Fit to your process | You change to fit it | Exact, and stays exact | Exact where it matters, standard elsewhere |
| Time to first value | Months, gated by configuration | Weeks per module with phased delivery | Weeks, on the module you choose first |
| Upfront cost | Licence plus implementation | Higher build, no licence | Licence on the core only |
| Ongoing cost | Licence, per seat or per transaction | Hosting, care plan, your own team | Both, on a smaller licensed footprint |
| Differentiation | None: your competitors run it too | Full, if the process is genuinely yours | Concentrated where it pays back |
| Upgrade risk | Their roadmap, their deprecations | Yours to schedule | Contained to the licensed core |
| Regulatory fit | Good where the product targets your sector | You engineer exactly to the rule | Custom where the regulator is specific |
| Exit cost | High: data model and process are theirs | Low: you own everything | Medium, and known per module |
The five-question test
Run these in order on each capability in the legacy system, not on the system as a whole. The answers usually differ by module, which is itself the finding.
- Would a competitor doing this differently beat us? If yes, build. If the process is invoicing, payroll or expense approval, the honest answer is no, and you should buy.
- Is a regulator specific about how this works? If a rule dictates fields, retention, consent or audit evidence, custom is often cheaper than bending a product to prove compliance.
- Will we genuinely change our process to match the product? Ask the head of the department, not the project sponsor. A no here means you will customise the product until it costs more than a build.
- How weird is our data? Fifteen years of historic codes, compound keys and locally invented statuses are migration cost either way, but a product will reject shapes it did not anticipate.
- What breaks if this vendor changes direction? Price rises, deprecations and acquisitions are normal. If the capability is load-bearing and the vendor is small, weight the risk accordingly.
A capability that scores build on the first two questions is where custom pays back. Everything else should be bought, integrated and forgotten about. The framework is generalised further on our build versus buy comparison page.
Why the hybrid answer is usually right
Legacy systems are rarely uniformly special. A fifteen-year-old ERP typically contains three genuinely bespoke workflows and thirty commodity ones that were only ever built in-house because no product existed when it was written. Treating the whole thing as one build-or-buy decision forces you to overpay on the commodity parts or compromise on the parts that matter.
Splitting it by capability produces a better programme and a smaller risk surface. You buy the general ledger and the HR module. You build the pricing engine, the compliance workflow or the dispatch logic that makes your operation different. You wrap both behind an API layer over the monolith so the rest of the business sees one coherent system regardless of what sits behind it. And you sequence the modules so each one delivers value before the next begins.
What each route costs
A bought platform costs the licence plus implementation, and implementation is where Eazyware's Enterprise Platform Implementation work sits, from $28,000 or ₹18,40,000 to $140,000 or ₹1 crore depending on modules and integrations. A custom build of enterprise scope through Custom & Enterprise Software Development runs from $24,500 or ₹16,00,000 to $175,000 or ₹1.2 crore. The hybrid path, replacing capability around a system that stays live, is the Legacy-to-AI Modernization Program at $31,500 or ₹22,40,000 to $105,000 or ₹72,00,000 and above. Published figures for all three are on the pricing page.
Running costs diverge after go-live. A bought platform charges per seat or per transaction forever, and that line grows with your business whether or not the product improves. A custom system costs hosting plus a care plan, from $1,000 or ₹68,000 a month at Essential to $5,250 or ₹3,40,000 at Enterprise with 24x7 cover and a named engineer. Neither is automatically cheaper over ten years; run the arithmetic on your own seat count before assuming.
Reversal cost: the number nobody calculates
Ask what it costs to change your mind in year three, because you might. Reversing a build is comparatively cheap: you own the code, the data model is documented, and you can migrate to a product at your own pace. Reversing a buy is expensive, because your data now lives in the vendor's shape, your people are trained on their workflow, and years of configuration encode decisions nobody wrote down.
Joel Spolsky's argument that rewriting from scratch is the single worst strategic mistake applies in both directions: the knowledge accumulated in a working system, whether written by you or configured into a product, is expensive to rebuild and easy to underestimate. Incremental replacement is the route that keeps that knowledge and keeps the option to stop.
When building is the wrong choice
We turn down custom work in three situations. When a mature product covers the requirement and the client's objection to it is preference rather than economics or regulation, buying is the better spend and we say so. When the organisation has no capacity to own software after handover, meaning no engineers, no budget line for a care plan and no appetite for one, a custom system becomes an unmaintained system within two years. And when the real problem is process disagreement inside the business, software of any kind sets the disagreement in code.
Buying is the wrong choice under a matching set of conditions: when the product's data model cannot express something your regulator requires, when the customisation needed to make it fit is already quoted higher than a build, or when the capability is the thing customers choose you for.
What this looked like in practice
A university's fifteen-year-old ERP covered admissions, fees and examinations. Two of those are close to commodity; examinations, with the institution's own grading rules and regulatory reporting, was not. A full product replacement would have forced the academic process to bend to a vendor's model mid-cycle, and a full custom rewrite would have rebuilt commodity capability at cost. The programme replaced capability module by module behind a stable interface, around the academic calendar, and is described in the university ERP modernisation case study.
Before you decide
- List every capability in the legacy system and score each on differentiation and regulatory specificity
- Get a written commitment from each department head on whether they will change process to match a product
- Price the product's implementation, not just its licence, and ask for a reference client of your size
- Estimate ten-year running cost for both routes at your projected seat or transaction volume
- Write down the reversal cost for each route in year three
- Decide who owns the system after handover and whether that team exists today
- Sequence the modules so the first one delivers value in under twelve weeks
Related reading
Application modernization vs rewrite covers the adjacent decision, The real cost of a custom CRM or ERP puts numbers against the build side, and Why enterprise software implementations fail on adoption explains what goes wrong when the buy decision is made without the people who will use it.
Decide capability by capability, and you will find the argument was never build or buy, but which parts of your business are actually yours.
Frequently asked questions
Is it cheaper to buy a platform or build custom software when modernising?
▾
Buying is usually cheaper upfront and more expensive over ten years, because licences grow with seats or transactions. Building costs more to start and then costs hosting plus a care plan, from $1,000 or ₹68,000 a month. Run the arithmetic at your projected volume rather than assuming either direction.
Can you mix buying and building in one modernisation programme?
▾
Yes, and it is the most common outcome. Buy the commodity modules such as ledger and HR, build the two or three workflows that differentiate you or that a regulator specifies precisely, and put an API layer in front so the business sees one system. This also keeps each decision reversible.
How do I know if a process is worth building custom software for?
▾
Two tests. Would a competitor doing it differently beat you, and is a regulator specific about how it works? A yes to either justifies custom. A no to both means the process is commodity, and any effort spent building it is effort not spent on the part of your business that actually differs.