Last Updated: August 6, 2026
How do you decide whether to modernize or rebuild?
Score each application on business differentiation, rate of change, and data gravity. Those three predict the right answer more reliably than age, language, or how much the team dislikes maintaining it.
Most portfolios get argued application by application, which is how the loudest stakeholder wins. A shared scoring model moves the conversation to evidence and makes the trade-offs visible to the people funding them.
What are the three scores?
Business differentiation asks whether this logic wins you customers. Rate of change asks how often it has been modified in the past 24 months. Data gravity asks how much other systems depend on its data model.
Score each from one to five using evidence rather than opinion. Differentiation comes from a product or commercial owner who can name what a competitor cannot copy. Rate of change comes straight from version control, which makes it the honest one. Data gravity comes from counting downstream consumers, integrations, and reports.
Run the scoring with the business owner in the room. Engineering consistently overrates differentiation for systems it finds interesting, and business owners consistently underrate data gravity because integrations are invisible to them.
What does each combination tell you to do?
High differentiation with high change rate justifies a rebuild. Low differentiation with a low change rate points to a package or a straight migration. High data gravity says decouple the data before touching the application, whatever else you decide.
The rebuild case needs both halves. A system that differentiates you but has not changed in three years is already doing its job, and rebuilding it spends money to arrive where you started. Sustained change plus real differentiation is what says the business needs room to move faster than the current codebase allows.
The migration case is the common one and the least glamorous. A 400,000-line order entry application modified twice in six years, encoding rules any commerce package already implements, is a migration or replacement candidate regardless of how much institutional pride it carries.
High data gravity changes sequencing rather than the verdict. When forty downstream consumers read the same tables, extract the data layer behind a stable interface first, then modernize the application behind it. Skipping that step is what turns an 18-month program into a 36-month one.
Which arguments should you discount?
Language age, developer preference, and vendor deadline pressure applied to the wrong system. Each one sounds like a business case and functions as a distraction.
COBOL running a stable, differentiating process with good test coverage is a reasonable thing to keep. Meanwhile a five-year-old microservice estate nobody can deploy safely may deserve consolidation. Age tracks maintainability loosely at best.
Watch for deadline bleed too. An SAP ECC end-of-maintenance date creates genuine urgency for the ERP core and none whatsoever for the twelve satellite applications a program manager attached to the same business case.
What to do next
Take your ten largest applications and score all three dimensions this month, pulling rate of change directly from version control so at least one number is beyond argument. The pattern usually resolves faster than expected, and the disagreements that remain are the ones worth executive time.
Read next: AI for Enterprise Application Modernization: Migrate, Automate, Govern
