Legacy software modernization
Improve the application your business already depends on
Your software still runs the work. But a small change now takes too long, a dependency is becoming difficult to support, or a new workflow no longer fits the way the application was built.
Better helps assess an existing custom application and scope its next useful improvement. We work through what must keep working, what should change and how to test the transition before agreeing the implementation.
30 minutes with Jai, Better's founder. Bring the current stack and one change that has become difficult.
01
Start with the change the business needs
An application can be old and still do its job. The reason to modernize is a concrete limitation: staff cannot complete a new process, releases repeatedly disrupt another workflow, or a component is constraining the next business change.
We start with that limitation. Who does it affect? What happens today? What would a useful first release let them do? Those answers help distinguish a contained improvement from a broader replacement.
A hosting move, a new interface and a change to business rules solve different problems. We make the intended result explicit before selecting a technical approach.
02
An assessment that leads to a decision
The initial scope depends on access to the application, its dependencies and the people who understand the work. We agree what will be inspected and what evidence the assessment should produce before it begins.
The proposed outputs are a map of the selected workflow and its dependencies; examples of required and disputed behavior; options with tradeoffs; and a first implementation scope with acceptance evidence, unresolved questions and an estimate. If the available information does not support a reliable build estimate, the assessment should explain what remains to be learned.
You should be able to decide whether to keep improving the current application, replace a specific part or investigate a larger change. Implementation is a separate commitment based on those findings.
03
Keep, upgrade or replace a bounded part
| Path | When it may fit | What must be checked |
|---|---|---|
| Improve the current implementation | The limitation is contained and the underlying design remains usable | Regression coverage, dependencies and the cost of continued maintenance |
| Upgrade a component or runtime | A supported upgrade addresses the constraint | Compatibility, dependency support and a way to recover from failure |
| Replace one workflow or component | A boundary can separate the change from the remaining application | Request routing, data ownership and dependencies that cross the boundary |
| Evaluate broader replacement | The required outcome cannot be reached through a defensible smaller change | Discovery gaps, transition costs and the business's ability to support both systems |
Microsoft's Strangler Fig guidance describes gradual replacement through routing between implementations. It also identifies limits, including situations where requests cannot be intercepted. A phased plan needs a workable boundary; the pattern name alone does not establish one.
04
Make the first replacement reviewable
Consider a hypothetical order-approval workflow. This is a sample decision asset, not a customer project or an implemented system.
The business wants a different authorized person to provide a second approval on orders of USD 5,000 or more. The existing application permits one approval at exactly $5,000 and has an unexplained customer exception.
- DecisionPreserve the below-threshold ruleEvidence for the first scopeAllowed and denied role examples at $4,999.99What it preventsLosing required behavior while changing the implementation
- DecisionChange the exact-threshold ruleEvidence for the first scopeOwner-approved results at $5,000 and $5,000.01What it preventsTreating every difference from the old system as a defect
- DecisionResolve the customer exceptionEvidence for the first scopeNamed policy owner, reason and approved dispositionWhat it preventsQuietly dropping a rule nobody can explain
- DecisionAssign the write ownerEvidence for the first scopeSpecify which implementation can change each in-scope recordWhat it preventsAmbiguous responsibility during coexistence
- DecisionDefine recovery after new writesEvidence for the first scopeDocument how changed records will be reconciled or replayed if the new path is stoppedWhat it preventsAssuming that reverting traffic also reverses business events
A real plan must define which amount the threshold uses, the currency convention, concurrent actions and any tax or discount rules. This example illustrates the decisions; it is not a production approval specification.
Martin Fowler's modernization discussion explains why recovering existing behavior is difficult and why copying all of it can preserve unnecessary work. We separate what the system currently does from what the business approves for the replacement.
05
Verify behavior and data separately
A replacement needs evidence for the work it performs and the information it carries forward. Record counts alone cannot establish that permissions, status transitions or historical relationships are correct.
For the selected workflow, the plan should define representative cases, denied actions, in-progress work and deliberate policy changes. Where data moves, it should also define record identity, meaningful fields, exceptions and the comparison boundary. Tool-level validation and application acceptance answer different questions.
Temporary routing, data comparison, support for both paths and eventual retirement belong in the scope. We also identify who can pause a release, what happens to work already processed and which reports or background jobs still depend on the old path. The transition ends when those dependencies and acceptance conditions have been addressed, rather than when the new screens look complete.
06
Know the delivery scope before committing
Better builds and improves custom applications through product, design and engineering work. Our working approach starts with the business problem and continues through implementation and feedback. The modernization scope still needs to match the application and the people assigned to it.
A named legacy runtime, proprietary platform, specialist database conversion or regulated workflow can require additional expertise. We confirm the required expertise and the engineers available for the identified stack before committing to implementation. If that fit cannot be established, the assessment should stop at its findings.
The estimate depends on the number of workflows, undocumented rules, testability, integrations, data quality and the transition the business can support. Access delays and unavailable policy owners are delivery dependencies too. We agree responsibilities and the first useful release before wider work begins.
For the broader architecture decision, read the refactor-or-rewrite assessment. If the immediate need is maintaining a product after a supplier handover, a product takeover assessment may be the more relevant starting point.
07
Bring one difficult change
Tell us what the application does, the current stack and the change you need. Include who uses it, what must keep working and who can explain the existing rules. Start with a description; arrange an authorized way to share code or data if a technical review is appropriate.
We will discuss fit, required skills and the scope of an initial assessment.
