A system that gives you trouble is not always a system that has to be replaced. Answer nine short questions about your system, and you will know three things:
whether you should keep and optimise it, build an extension on top, phase it out gradually or replace it outright
what the least risky order to do it in would be
whether the numbers carry the decision, or whether you should wait
Hard → safe to build on top
Build on top and phase out
Build an extension on top
Replace the system
Keep and extend within the system
The core system: unfit → working well
What we are noting down
System: {system}
Today: {idag}
From now on: {lettere}
The core system handles data and transactions reliably.
The core system works, but with a fair number of manual workarounds.
The core system can no longer support the processes properly.
The problem looks mostly like process, data or training. Perhaps nothing new needs building at all.
The system is end of life or unsafe. That pulls towards phasing it out.
The system is ageing or dependent on a few specialists.
The system is the clear source of correct data.
Data quality is uncertain. A new surface can hide that, not solve it.
The problem lies in the experience around the system: that argues for an extension on top.
The problem lies in the core model itself.
The system can exchange data safely through an API.
The system is closed: a robust extension becomes more expensive.
The core data and rules can stay in the system. A clean extension is possible.
Temporary double keeping with an end date: only as part of a gradual replacement.
A permanent copy of the core data and rules is a shadow system, not an extension.
A replacement would be manageable: few users and integrations.
Many dependencies: a replacement should be gradual, if it happens.
There may already be a feature or an upgrade available to you.
An off-the-shelf system may fit better. We are noting that for the route to build.
The market has not been looked at yet. That should happen before custom development.
The basis rests mostly on a gut feeling. We are noting that.
There is a measured baseline behind the problem.
There is someone in charge, a KPI and a timeframe.
The problem takes up about {timerAar} internal hours a year.
0 of 15 answered
Answer every question to see your estimate.
Your estimate
The system is probably not the main problem
Estimate: keep and optimise
Your answers point to a core system that works, a system that is supported, and a problem that is mainly about process, data discipline, training or a feature you already have access to. Then the cheapest and best answer is to put that right first, before anyone builds anything new. A new interface on top of a core system that works is rarely the right place to start, if the real friction sits somewhere else.
Assumptions behind the estimate
That the core system really is healthy, and that the daily friction can be removed with process, data or a feature you already have. If it turns out that users have a real need the system cannot meet, the picture changes.
This would change the answer
If customers or staff need a new self-service or workflow that the system cannot deliver itself, the estimate moves towards an extension on top.
A discovery call would answer this
Which specific process, data discipline or configuration gives you the most, and whether an existing module or upgrade can meet the need without building anything new.
Your estimate
Keep the system as the core, and improve the experience around it
Estimate: build an extension on top
The core system works, and it can be built on safely: the data is reliable, integration is possible, and the new solution can avoid copying the rules held by the core. Then the answer is an extension on top: a new user experience, self-service or workflow on top of the existing system. The customer or the member of staff meets one simple surface, while the ERP, the CRM or the line-of-business system carries on as before and still owns master data, stock, finances and the final transaction.
What the solution could look like
Customer or member of staff
Web component, portal or web app
Coignite integration and process layer
Existing ERP, CRM or line-of-business system
Assumptions behind the estimate
That the extension can make do with owning its own new process, status, documents and notifications, while the core system still owns master data, calculations, stock and finances.
This would change the answer
If in practice the new solution has to copy the core data and rules permanently, it is no longer an extension but a shadow system, and then a real replacement should be considered instead.
A discovery call would answer this
Exactly what should still be owned by the existing system, what should move out into the extension, and what the first concrete step should be.
Your estimate
Solve the urgent need now, and make the solution the first part of the future system
Estimate: build on top now, phase out gradually
The system is on its way out, or it can no longer be built on safely, but replacing all of it in one go would be too risky right now. Then the defensible route is a gradual transition: build a new solution that both solves the urgent need and becomes the first building block of the future system. Function by function is moved across until the old system can be phased out. The approach matches the Strangler Fig pattern, where value is delivered and checked along the way instead of in one large leap.
What the transition could look like
New user experience
New process and integration layer
Old system and new services side by side
Functions and data move across step by step
The old system is phased out
Assumptions behind the estimate
That every new function can be given a clear data owner, that any temporary double keeping has an end date, and that the new components are designed to outlive the old system.
This would change the answer
If the core system is healthier than the answers show, a plain extension on top may be enough. If the dependencies are smaller, a single replacement may be realistic.
A discovery call would answer this
Which function should move first, what the phase-out order looks like, and how old and new run safely side by side along the way.
Your estimate
The problem lies in the core system, and a new interface would mostly hide it
Estimate: replace the system
Your answers point at the core system: it is end of life or unsafe, central data and processes do not hold, safe integration is hard, or an extension would end up copying the core data and rules. Then a new interface does not solve the problem, it hides it. The honest answer is to replace the system. One important point: replacing a system rarely means building a new ERP from scratch. More often it means finding an off-the-shelf system that can be the new core, and building only what is specific to your business around it.
Assumptions behind the estimate
That the problem really does lie in the data model, the business rules or the life cycle of the system, and not only in the surface around it.
This would change the answer
If the core system is healthier than the answers show, and the problem is mostly about the user experience, an extension on top is both cheaper and faster.
A discovery call would answer this
Which core processes, data ownership and integrations the future calls for, and which off-the-shelf systems should be assessed before any decision about custom development.
Your estimate
There is not yet enough to go on to choose responsibly
Estimate: get the basis clear first
Your answers pull in different directions: the core system is not bad enough for an obvious replacement, but a safe extension is difficult at the same time, or it is unclear which data is correct, how the system can be integrated, and what the supplier can actually offer. Choosing now would be a guess. The wisest next step is a short review of the system and the processes around it, so the basis is visible before a solution is chosen.
Assumptions behind the estimate
That the most important unknowns, data quality, integration options, the plans of the supplier and the size of the problem, have not been settled yet.
This would change the answer
Once integration options and data quality have been mapped, the answers usually point clearly towards either an extension on top or a replacement.
A discovery call would answer this
Which few investigations it takes to be able to choose with confidence, and how a short, well-bounded review is approached.
Why this estimate?
The core system can actually do what is needed, so the problem looks mostly like process, data or training.
The system is end of life or unsafe, and it should not carry a permanent extension.
The problem lies in the core system, and a new surface on top would hide it rather than solve it.
An extension would have to copy the core data and rules permanently, and that is a shadow system.
The system can only be reached through workarounds, so a robust extension becomes expensive and fragile.
The system can exchange data safely, so an extension can be connected properly.
The core data and rules can stay in the system, while the new solution owns only its own process.
The problem lies in the experience and the workflow around the system, not in the core.
Many dependencies make a gradual transition more defensible than one single replacement.
Data quality is uncertain, and a new interface cannot repair it.
There is already a module or an upgrade that could probably meet the need.
Recommended route to build
Configure what you already have
Your current system probably has a module, an upgrade or a feature that can meet the need. Configure or upgrade that first, and measure the effect, before anyone builds anything new.
An off-the-shelf system as the new core
You judge that an off-the-shelf system fits considerably better. If the system is to be replaced, put an off-the-shelf system in place of the core rather than custom building a new core from scratch, and build only the functions specific to your business around it.
A short market check first
The market has not been looked at yet. Look at your current supplier and two or three relevant off-the-shelf systems before custom development is recommended. An off-the-shelf core can often cover most of it, so you only build the special part around it.
Custom built may be relevant
The workflow has rules of its own, several parties or connections across systems. That is where a custom extension or modernisation pays for itself: a new experience on your website or portal, connected safely and under control to your systems, with status, documents and workflows gathered behind it.
Put the workflow right first
There is no route to build to recommend, because the estimate says the system is not the main problem. Start in the workflow: agree who records what and when, tidy up the data that gives you trouble, and give people the training they are missing. Measure the effect afterwards. If the problem is still there, you at least know it was not the process.
Route to build once the basis is clear
The route to build cannot be chosen yet, and a guess here costs more than a review. Spend the short review on the three things the choice rests on: what the core system should still own, what can move out, and what your current supplier and the market can already do. Once those three are clear, this tool gives you a sharper answer.
Is the business ready?
Document the basis first
The direction is technically possible, but the business case has not been documented yet. On your numbers the problem comes to about {timerAar} internal hours a year. Put someone in charge, a baseline and a target in place before you invest, so the decision rests on more than a gut feeling.
A prototype or a bounded analysis
On your numbers the problem comes to about {timerAar} internal hours a year, and there is a reasonable basis. The next step is a bounded analysis or a prototype that tests the assumptions before the full solution is decided.
Ready for a solution specification
On your numbers the problem comes to about {timerAar} internal hours a year, and there are numbers, someone in charge and a target behind it. You are ready for a solution specification and a real investment decision.
A smart new interface does not move a core problem, it hides it. That is why the answers about the core system weigh more heavily in the estimate above than the answers about the experience.
A permanent copy of the central data and business rules of the system is not an extension but a new shadow system, which over time becomes more expensive and more fragile. It can only be defended as part of a deliberate, gradual replacement.
A system that is end of life or unsafe should not be given a permanent extension as a long-term strategy. Carrying on after the support period normally raises either the risk or the cost of compensating for it.
Replacing a system should not be recommended before your current supplier and the relevant off-the-shelf alternatives have been looked at. A short market check costs little now and can save a whole wrong purchase later.
The needle shows the technical picture of the system. Your answers point to a problem that is mainly process, data or training, and that is what decides the estimate above.
Does the estimate look familiar? Then we would be glad to look at the system together with you. The business case never changes the technical conclusion, only how big the next step should be. And if the tool tells you the system is not the main problem, that is a perfectly useful answer, even when it means less work for us.
The estimate rests on your answers here alone, and it does not replace a proper review of the system and the processes around it. It is a starting point for a conversation, not a verdict.
The estimate is based on what you know about the system today. How easy it is to build on top also depends on the integrations and documentation that already exist, and that is something we can only see once we look at it together.
Could you use the estimate?
What went wrong?
Thanks for the feedback.
Frequently asked questions
When does the question of replacing a system come up?
Typically when a system you have lived with for years starts getting in the way. Customers cannot see a status for themselves, a workflow runs on emails and spreadsheets, management has no overview, or the supplier gives notice that the system is on its way out. The discussion then quickly gathers around two extremes: do we carry on living with it, or do we replace the whole thing? Both answers are often wrong, because they skip the most valuable question: what should the system still own, and what can move out.
Established modernisation models (the so-called six Rs) distinguish precisely between keeping, upgrading, rebuilding, repurchasing, rearchitecting and retiring a system. This tool boils that down to five usable outcomes and helps you choose the one your answers actually point to, rather than the one that feels most pressing right now.
What is the difference between an extension on top and a new system?
An extension on top puts a new user experience, self-service, workflow or integration on top of the existing system, which still owns master data, prices, stock and finances. The customer or the member of staff meets a new, simple surface; behind it your ERP, CRM or line-of-business system carries on as before. A flexible process and data layer can own the new self-service process, status history, documents, notifications and approvals, while the core system still owns stock, prices, balances, bookkeeping and the final transaction. A new system replaces the core itself.
The extension is faster and cheaper when the core works, but it cannot repair a system whose data, rules or life cycle have broken down. And there is one hard rule: an extension must never copy the core data and rules permanently. Then it is no longer an extension but a new shadow system. Temporary double keeping can be acceptable, but only as part of a deliberate, gradual replacement with a clear end date.
When is an extension on top the wrong solution?
When the problem lies in the core system. If the system is end of life or unsafe, if the data is unreliable, or if the new solution would have to copy the core rules and data permanently, then a new surface merely hides the problem. It becomes a shadow system that in time is more expensive and more fragile than the one it was meant to replace.
Does "replace the system" always mean rebuilding everything from scratch?
No, and that is an important point. Replacing a system most often means finding an off-the-shelf system that can be the new core, and building only the functions specific to your business around it. If the dependencies are large, the wisest replacement is a gradual one: functions move step by step from the old system to the new, so you deliver and check value along the way instead of in one large leap.
What does it mean to phase out a system gradually?
To build a new solution that both solves the urgent need now and becomes the first building block of the future system. Function by function is moved across, every new part gets a clear data owner, any temporary double keeping has an end date, and the new components are designed to outlive the old system. In the end the old system can be switched off. The approach is known as the Strangler Fig pattern.
Why does the tool ask whether we have looked at the market?
Because replacing a system should not be recommended before your current supplier and the relevant off-the-shelf alternatives have been looked at. Often a module you already have, or an off-the-shelf system, can cover most of the need. A short market check costs little now and can save an expensive wrong purchase or an unnecessary development project later.
What is the role of Coignite in this?
We help you with the most valuable question: what should still be owned by the existing system, what should move out, and what the first concrete step is. With web components, a flexible integration and process layer and an understanding of process, we build the extension or the gradual modernisation, so the core system keeps what it is good at and users get the experience they are missing.
Trusted by
Do you have a project in mind or are you looking for inspiration?
We love challenges. And if you are faced with a project that needs either to be initiated, optimized or even saved, we would like to offer our proposal for a solution.
A reply from one of us by the next business day.
A no-obligation review of your situation.
Clarity on which options are relevant to you.
A concrete plan, if you choose to go ahead.
Click to comment
Help us make this page clearer
Click the part that did not make sense — or where something was missing.
