Low-code platforms are a sensible way to get a first version of an internal tool or customer process running quickly. Many companies then use the same platform for years, and some reach a point where it costs more than it saves. This article is for heads of technology who suspect they are at that point. It offers a checklist for deciding whether to move, and a way to move in stages instead of in one risky rewrite.
If you are still trying to understand what is going wrong, start with our article on where low-code platforms break. Here we assume you have seen the symptoms and need to decide what to do.
First, is moving really the answer?
Outgrowing a platform is not the same as the platform being bad. A tool that served you well for three years has done its job. The question is only whether the next three years are cheaper and safer on it or off it. Staying is a legitimate result of the checklist below, and sometimes the right answer is to move one part and leave the rest.
Be careful with two common reasons that do not hold up. "Developers dislike the platform" is a real cost if it affects hiring and speed, but it needs to be written down as a cost. "It is not what we would build today" is true of almost every system and is not a reason on its own.
The checklist
Go through the four areas below with the people who run the system every day, not only with its sponsor. For each one, write a short answer and the evidence behind it.
1. Limits you cannot get around
- Is there a feature the business needs that the platform does not support, and for which the answer from the vendor is "on the roadmap"?
- How many workarounds does the team maintain: scripts outside the platform, manual exports, duplicated data, extra tools that exist only to fill a gap? List them. A short list is normal; a list that grows every quarter is a signal.
- Are there platform limits on records, API calls, users, file sizes or automation runs that you now plan around?
- Can you test changes safely, with separate environments and a way to roll back, or does every change go straight into production?
2. Total licence and running cost
Licence price per user is only a part. Add everything else that you pay because of the platform:
- licences, including add-ons and the tier you were forced into by a single feature;
- platform-specific developers or consultants, whose time often costs more than general developers;
- extra tools and integrations that exist to cover platform gaps;
- time lost to workarounds and manual steps.
Then look at how the price changes when you grow. A model that charges per user, per record or per run behaves differently from one that charges a flat fee. Here is a worked example with invented figures, only to show the arithmetic. A platform costs 40 per user per month and you have 120 users: 40 × 120 × 12 = 57,600 per year. If the user count doubles, the licence doubles to 115,200, while the cost of running a custom system would grow much less. Use your own numbers, and compare over three to five years, because a rebuild costs money at the start. Our guide to the real cost of custom software can help you estimate that side, and the business case for custom software shows how to present it to finance.
3. Performance under real load
- Where is the system slow today: opening screens, reports, searches, scheduled runs? Collect a few concrete timings instead of impressions.
- What happens at your busiest day of the month or year? Does it slow down, fail, or hit a limit?
- Can you tune it yourself, or only ask the vendor?
If the platform copes today but you expect volume to grow several times over, test with realistic data before deciding. A simple load test on a copy often answers the question.
4. Lock-in and exit
This is the area that is most often checked too late. Ask:
- Can you export all your data, including history, attachments and relationships, in a usable format? Try it on a real sample, not just read the documentation.
- Can you export the logic: rules, workflows, forms and permissions? On many platforms you can take the data but not the behaviour, which means that the behaviour must be described and rebuilt.
- Who owns the data model and the documentation? If the only description of how a process works is the configuration inside the platform, you have to reconstruct it from the running system.
- What do the contract terms say about notice, price changes and the period after termination?
For vendor-side questions that apply to any supplier, see our framework for build versus buy decisions.
Reading the result
Do not turn the checklist into a score that decides for you. Instead, sort the findings into three groups:
- Stay: limits are minor, cost is predictable, performance is fine. Write down what would change your mind, and review in a year.
- Move a part: one or two areas hurt, for example a customer-facing process that has hit a limit, while the rest works well. This is the most common result.
- Move most of it: cost, limits and lock-in all point the same way, and the workaround list is long.
Even in the third case, "most of it" does not mean "at once".
A plan to move in stages
A big-bang rewrite stops the business for months, asks the team to describe everything in advance and puts the whole risk on one switch-over date. Staged migration spreads the risk.
Stage 0: describe what exists. Before building anything, document what the platform really does: the data, the processes, the integrations, who uses what and how often. Include the unwritten rules that people apply by hand. This often reveals that some features are no longer used, and you can leave them behind.
Stage 1: choose the first part. Pick one part that satisfies three conditions: it hurts the business enough that the result will be visible, it has clear boundaries, and it can run next to the old system for a while. A customer-facing portal or a heavy reporting function is often a better start than the core data store.
Stage 2: build the new part and connect it. The new part reads from, or writes to, the old system through an interface, so the two work together. Keep the interface small and documented, because it will change as more parts move.
Stage 3: run in parallel and compare. For a defined period the same cases go through both. Compare results on real data, and let a small group of users work in the new part first. Write down what differences you accept and what you do not.
Stage 4: switch over and keep a way back. Move users in groups. Keep the old part available and read-only for a defined time so you can go back if something is found late. Agree in advance who decides to go back and on what evidence.
Stage 5: retire and repeat. Turn off the old part, cancel what you no longer need, record the saving or the problem, and use what you learned to choose the next part. Moving the data store itself usually comes last, when most of the logic around it has already moved.
For discovery work that reduces the risk of a custom build, see our article on de-risking custom builds in discovery.
Common mistakes
- Recreating the old system exactly. A migration is a chance to drop unused features and fix processes that were shaped by platform limits.
- Underestimating the data. Cleaning and mapping data often takes longer than building the screens. Start the trial exports early.
- Moving the hardest part first. Start with something valuable but manageable, and learn before you tackle the core.
- Having no measure of success. Decide before the first stage what you will compare: time to make a change, cost per month, error rate, user complaints.
- Ignoring the people who built the original. Citizen developers and business owners know why things work as they do. Involve them from stage 0.
What to bring to the decision
A one-page summary is enough: the answer to each of the four checklist areas with evidence, the three-to-five-year cost comparison with the assumptions marked, the first part you would move and why, and what would make you stop or go back. If you already know that you want to move but are unsure about the first part, a short discovery phase is usually cheaper than a wrong first stage.
Sources
- Documentation of your own platform for export, limits and pricing tiers (check the current version before relying on any figure).
- Our related articles linked above; all figures in the worked example are invented for illustration.
