How to evaluate enterprise and legacy software before acquisition — on-premise deployments, large database migrations, customer customizations, integration dependencies, and the true cost of modernization.
Enterprise software acquisitions are high-stakes and long-tail. The deal closes in months. The integration and modernization work plays out over years. Technical due diligence here is less about "is the code clean" and more about "what will this actually cost to run and improve after we own it."
Enterprise software — whether ERP systems, industry-specific platforms, or long-tenured SaaS with large enterprise contracts — has a different risk profile from modern SaaS. The technology may be old. The customers may have been there for a decade. The customizations may have grown to dwarf the core product.
This guide covers the specific evaluation challenges of enterprise and legacy software acquisitions.
Don't evaluate the technology in isolation — evaluate the technology in the context of the team and the customer base.
| Technology concern | Low risk | High risk |
|---|---|---|
| PHP 7/8, Java 8+, .NET Framework | Large talent pool, stable | Fine if maintained |
| PHP 5, Java 6/7, Classic ASP | Limited talent pool, security concerns | Modernization required |
| Proprietary languages or frameworks | Depends on community | Vendor dependency, hiring risk |
| End-of-life OS dependencies | Plan to remediate | Active vulnerability surface |
| On-premise only, no cloud path | Migration planned | Customer lock-in, operational burden |
The real question: Can you hire the developers needed to maintain and improve this system? A legacy Java system with a large Java developer community is manageable. A system built in a niche proprietary framework with three people in the world who understand it is not.
Enterprise systems often have massive, complex databases:
Ask for the database schema and look specifically for:
This is the most important and most difficult part of enterprise software DD.
Step 1: Map the customization surface
Ask for a list of all customer-specific customizations. Every enterprise vendor has them. If the seller says "we don't do customizations," that's either untrue or it's a significant selling point worth verifying.
Step 2: Classify each customization
| Type | Description | Risk |
|---|---|---|
| Feature flag | Customer-specific behavior behind a flag | Low — manageable |
| Separate module | Customer code in a dedicated, isolated module | Medium — maintainable but adds complexity |
| Core product modification | Customer-specific change in the main product | High — can break other customers |
| Database schema change | Customer-specific tables or columns | High — migration complexity |
| Custom integration | One-off integration built for a single customer | High — undocumented dependency |
Step 3: Ask the question no one asks
"If your three largest customers cancelled tomorrow, what code would you need to remove?"
The answer reveals how much of the codebase is held hostage by specific customers.
Many enterprise systems run on customer infrastructure. This creates:
Support complexity:
Security patch responsibility:
License and compliance:
Enterprise software is the hub of a larger ecosystem. Map all integrations:
For each:
Red flag: Integrations built by a single engineer who has since left, with no documentation.
Enterprise software acquisitions often come with a modernization narrative: "We're going to move this to the cloud / rewrite it in modern tech / build a proper API."
These plans are almost always more expensive than projected. Before buying into a modernization narrative, evaluate:
Can the business function during migration? Enterprise systems typically can't go offline for re-platforming. Migration must be parallel, which doubles the engineering cost.
Will customers accept the changes? Enterprise customers who have been using the same UI for 10 years resist change. Modernization can trigger unexpected churn.
Are the data migrations scoped? Moving a decade of enterprise data to a new schema is not a weekend project. Get a scoped estimate from engineers who have actually done it.
What are the contractual constraints? Customizations may be contractually guaranteed. A modernization that removes a customer-specific feature they paid for can trigger breach of contract.
Rule of thumb: Whatever the internal estimate is for modernization, double it for the first major milestone and triple it for full completion.
Before closing, answer:
Evaluating an enterprise or legacy software acquisition? Contact us — we conduct enterprise software technical due diligence with specific expertise in legacy system assessment, customization audits, and modernization cost estimation. We've reviewed systems ranging from 5-year-old SaaS to 20-year-old on-premise platforms.
If this guide resonated with your situation, let's talk. We offer a free 30-minute discovery call — no pitch, just honest advice on your specific project.
Your developer went silent. Your project is half-built. You don't know what state the code is in. This is the step-by-step guide to recovering your project and getting back on track.
10 min readRescuing SoftwareHow enterprise buyers should evaluate SaaS vendor security — what certifications actually mean, what to look for in security questionnaires, data residency requirements, incident response, and the contract clauses that protect you.
11 min read