Modernise without the place standing still.
Your platform does its job. It is just ten years old, every change costs three times what it used to, and nobody dares go near the parts your money runs through.
We replace it piece by piece while people keep working in it. Not a rebuild you wait a year for and then have to hope is right.
You know yourself when the time has come.
There is rarely one moment. It creeps in, and one day four people say the same thing.
-
A small change takes a week
What used to be an afternoon is now a sprint, because every adjustment can break three other things.
-
Updates keep being postponed
The language or the framework is several versions behind and nobody dares make the jump, so the gap keeps growing.
-
Nothing will connect any more
You want to hang your accounting, your webshop or your warehouse off it, and there is nothing to connect to.
-
You cannot find people for it
Developers willing to maintain this are getting scarce, and the one who knows it will leave one day.
Why we do not rebuild it all at once.
The big rebuild gets proposed far more often than it gets finished. This is why we will not start one, however attractive it sounds.
-
It takes twice as long
What is planned for six months becomes eighteen. That is rarely down to the technology and almost always down to there being more in the old system than anyone knew.
-
Half of it is written down nowhere
Ten years of exceptions are baked in. That one customer with their own prices, that one order type on a Friday. In a rebuild you meet them when someone calls.
-
You pay twice
The old system keeps running in the meantime and still needs maintaining. So you work on two platforms at once for a year.
-
There is no point to stop
Until it is completely finished you have nothing usable. If the money runs out or the plan changes, you are left with empty hands.
How we do it instead.
We put something next to the old system and slowly drain it. After every step something real is running, and you can call it enough at any point.
Book a call-
Measure what actually gets used
We look at which screens and functions are genuinely being clicked. Usually a third of what is there has been idle for years. So we do not rebuild it, which saves time and money right away.
-
A layer between old and new
We put a connection between the existing system and whatever comes next. From then on the two can run side by side and nobody on the floor notices anything changing.
-
Replace it module by module
We take one piece at a time, put it live and see how it lands. If it does not work as intended we put it back. Meanwhile everything else keeps running.
-
The old one goes
Only once nothing leans on it any more does the old code come out. That is often a year later, and usually nobody outside the team noticed.
Platforms we brought back up to date.
Existing software, replaced piece by piece without the work coming to a stop.
All cases-
De app en de API waarmee een SOS binnen seconden bij vrijwilligers in de buurt ligt.
Een SOS die binnen seconden op de telefoon staat van vrijwilligers een paar straten verderop.
-
De app die hun magazijnsysteem en Shopify aan elkaar knoopt, te installeren vanuit de App Store.
Voorraad die in het magazijn afgaat en op hetzelfde moment in de webshop klopt.
-
De vernieuwde site met een configurator waarin klanten hun eigen pakket samenstellen en meteen bestellen.
Bestellingen die binnenkomen zoals de klant ze zelf heeft samengesteld, klaar om te verwerken.
CodeIQ thinks along with you and has an answer for everything. A driven company that will not leave you hanging.
Questions about modernising.
Not answered here? Just ask. You get someone who runs these projects themselves.
Ask your questionWould we not be better off starting from scratch?
Sometimes yes, and then we say so. If it sits in a language hardly anyone works with, or the process itself has changed so much that you need something different, rebuilding it as it was is a waste of your money. In the vast majority of cases, replacing it step by step is cheaper, visible sooner and a lot less frightening.
How long does this take?
It depends on the size, but the first step is usually live within six to eight weeks. The whole thing often runs for a year or more. That sounds long, except you have something in hand every month rather than only at the end.
Will our platform be down in between?
No. Every step goes up next to the existing system and only takes over once it works. Where a switch genuinely has to pause things, we schedule it outside office hours, and then you are talking minutes.
Will our people have to learn everything again?
Not in one go. Because we replace module by module, one screen changes at a time. That settles by itself and saves a training project nobody is waiting for. Where the new way genuinely works differently, we walk through it with the people who use it daily.
What if we want to stop halfway?
Then you stop. Everything we replaced up to that point runs and is yours. That is exactly why we work this way: you are never locked into something that only pays off in a year.
Are we not paying twice, old and new side by side?
For a while there is more running, yes. But you have to maintain the old system as long as it stands anyway, and in a big rebuild you do that for a year with nothing to show. In our approach a piece of that maintenance falls away every few months.
Can new things still be added along the way?
Yes, and it is often the right moment. New wishes get built straight into the new part, so they do not have to be built twice. That way a modernisation partly pays for itself as it goes.
What happens to our data?
It moves along, and that is usually the hardest part. We run the migration on a copy a few times first, check the counts and the amounts, and only switch when it adds up. The old database stays around for a while afterwards, in case something has to come out of it.