Legacy systems
An old system carries the business logic your organisation runs on today. We replace it one clearly bounded function at a time, while it stays in service, rather than rewriting everything at once.
A system in production holds more than its source code. It holds exceptions, special cases and agreements made over the years, and some of them exist only in the code. Some should go, others carry the business. Replace one function at a time and you can decide that function by function, with the old system running alongside as the answer key, instead of needing the whole picture before anything new can be used.
How do you modernise without a big bang?
You put a facade in front of the old system and route the calls you can control through it. Functions then move behind the facade to new code one by one, and the systems calling it keep using the same address. Whatever does not go through the facade, such as scheduled jobs and shared databases, needs a plan of its own. The old system shrinks until it no longer does anything, and can be switched off.
The four jobs of the facade
- Route. Decide which implementation handles a call, per route and ideally per share of traffic.
- Translate. Keep the old system’s formats away from the new services.
- Fall back. Send traffic back to the old implementation by changing the routing, without a new deployment. That only works if the old system can still read what the new code has written, so it gets tested, not assumed.
- Observe. Log comparably on both sides, so a difference in response or response time can be seen and compared rather than guessed at.
We test the way back before traffic moves, not after. Can the old code read what the new code has written? Are there payments, emails or other side effects that cannot be undone and need handling on their own? Once that is answered, we move a small share of traffic, watch the logs and move more.
Where do you start?
Map the dependencies first. Then pick a function with clear inputs and outputs, few dependencies on the rest, and something the business wants improved, so the move delivers more than new code. Measure response times and error rates before you touch anything, and decide in the same delivery when the old code goes. If the history has to come along, see data migration.
Move one function at a time, and decide how you move it back before you move it.
Need help with legacy systems?
CONTACT US >Need help with integrations, code or a broken system?
Fill in the form or email us at hello@webringcode.com, and we’ll get back to you with how we can help.
Or call us directly on +46 10 660 04 20.