Draft for Tamir's review. Not published.
Find the measured constraint
Ask for the measured failure: what breaks, at what load, with evidence from tests or incidents. Then ask for the smallest change that removes it. A slow batch run may come from new upstream checks and waits, while the old platform gets the blame.
If a new product needs the change, map its requirements to constraints the current system demonstrably cannot meet. Compare a limited modernization, a parallel capability and a full replacement against the same list.
Protect the knowledge inside the old system
In a system built in-house over years, the rules are the asset at risk. Document the decision rules and data flows while the people who know them are still there. Both paths need that.
When a vendor offers an expensive upgrade or its new product, add the option it left out. Get one alternative vendor's price for the same scope, even if you intend to stay. Ask in writing how long the upgraded version is supported.
Depending on your seat
If you're on the board and the old system still runs years after its replacement, ask what still runs on it and who uses it. Ask what keeping it costs each year. Set a decommission date and fund only the sequenced plan to reach it.
If you run IT, choose the cutover approach from your data and products. A single cutover works when the data is clean, the products are few and rollback is real. Otherwise move piece by piece, with a named list allowed to stay on the old system until an end date.
What to check before you decide
- Ask for the measured failure that justifies the change, with evidence from tests or incidents.
- Separate standard processing, your own business logic and integrations, and size each.
- Test any package on ten of your hardest real cases and see where it needs customization.
- Get one alternative vendor's price for the same scope as the proposed replacement.
- Ask each vendor what a failed cutover looks like and how long rollback takes.
- Price the yearly cost and risk of running the old system alongside the new one.
- Set an end date for the old system and an owner for reaching it.
Questions people ask
We still run our old core alongside the new one years after replacement, how does the board get the decommissioning finished?
Ask what still runs on the old system, who uses it, what migrating each piece costs and what keeping the old system costs each year, including its risk. Then set a decommission date with the pieces sequenced, and fund only that. It depends on how many functions remain and on whether some can be retired rather than migrated.
My CTO wants a rewrite and sales wants features now, how do I decide what the company does next quarter?
Ask the CTO what specifically fails at what load and what the smallest change is that fixes that, and ask sales which one feature closes the most pipeline. Most rewrites can be staged around the real bottleneck while one feature ships. It depends on whether the scaling problem is measured or feared, and on whether the pipeline is real.
Our system vendor offers an expensive upgrade or a full replacement with its new product, how do I decide between them?
Add the third option the vendor left out: another vendor's product, priced for comparison, even if you intend to stay. Then decide on what the business needs in five years and what each option forces you to do before then. It depends on how long the vendor supports the upgraded version and on how much your processes would change under the new product.
Replacing our plant control system, incumbent migration or competitor cutover, how do I weigh production risk against cost?
Price the production risk: a day of lost production times the realistic chance of a cutover problem under each offer. Then compare twenty years of support and change costs, which usually matter more than the purchase price. It depends on how the cutover would be staged, what fallback each vendor commits to, and what the plant's turnaround schedule allows.
Do we need a new insurance core platform to launch digital products?
Identify which product requirements the current core cannot support and compare the feasible remedies. It depends on existing policy obligations, support limits, interface capability, and the ongoing cost of coexistence.
Core insurance system replacement, big bang cutover or migrate product by product?
Big-bang works when the data is clean, the products are few and a rollback is real. Product-by-product works when products differ a lot and the business can tolerate two systems for a while. It depends on your data quality, the number of distinct products and how long you can run in parallel.
Our in-house credit system depends on two engineers near retirement, replace it with a package or modernize it in place?
First extract and document the rules while the engineers are available, because both paths need that and it is the asset at risk. Then compare the package on how it handles the rules that make your lending different. It depends on how much of the system is standard processing and how much is your own credit logic.
Identity platform migration under way and many apps use unsupported authentication, keep two systems or fix the apps?
Group the hard applications by what it takes to move each one: a configuration change, a vendor upgrade, a proxy in front, or a rewrite. Most fall in the first three. Keep the old platform only for a named short list with an end date. It depends on how many applications need vendor action and on how long the old platform can be kept secure.
Should we replace legacy financial processing or remove specific performance bottlenecks?
Map the critical path before choosing a rewrite. The right intervention depends on dependency waits, avoidable serial work, and whether changed processing preserves business results.
Does our startup have a business reason to move to microservices?
Separate a component only when a concrete constraint justifies the operating cost. The choice depends on coupling, deployment needs, scaling evidence, and who can own the resulting services.
How I can help with this decision
- Ask or talk (Free)
- I give my view on which path your system's mix of standard and custom logic favors, and the first check to run before you believe any timeline.
- Review (Pay if it was worth it)
- I write an independent assessment of the system's real limits, the options and the cost of running old and new together. I recommend upgrade, modernize, replace or a staged mix, with a plan.
- Retain (When it makes sense)
- I stay close through the chosen path to review cutover readiness at each gate and the decommissioning progress.