Replacing legacy systems: Proxy to learn and control

TL;DR – Create a custom proxy to make sure you know how the old system behaves and can transition off it in a controlled manner.

A couple of weeks back I held a talk at JavaZone about replacing legacy systems (Norwegian only, sorry). One of the techniques I talked about that seemed to spark an interest was creating a custom proxy to take control and figure out what the old system does.

Not a dedicated proxy like Nginx or Apache, a custom proxy in the language and technology you are comfortable with. It can ease the replacement and transition a lot.

For us that was KTor Server+Client.


When you have a system with a Webapp, Mobileapp and API like this:

You can take control of the system by introducing a proxy like this:

Simple as that. 😉 HTTP request in, HTTP request out, receive response and send response back to the source. A bit of fiddling around, but you essentially copy everything forward and back. Headers, Method, response codes and of course body.

The figure above also shows how we used the proxy to double check some data results in the DB before switching out the legacy system (the dotted lines).


By creating a custom proxy you can monitor, log, analyze and even compare results. All in your preferred development language.

When you gain insights into how your system is working, you can manage which parts controls and receives each call.

Wan’t to switch over based on user-id? That’s a simple conditional statement in your proxy code.

Switch gradually based on endpoints? Even easier, just change which system is the recipient for your call.

Subscribe new content:


We used KTor Server+Client because it made it easier to know that coroutines were handled correctly but you could also use OKHttp as a client if you wanted.

Be careful with big payloads though, stream the results as a default, and only load the body into memory if you know the size and actually need to analyze or modify (don’t) it.

I don’t have the proxy as an example myself but this doesn’t look like a bad starting point:


Yeah, that’s harder. But still just streams of bytes back and forth. Even Cobol Copybooks has a format that can be parsed. 🙂

Happy migrating 😉

What’s your best techniques for migrating off legacy systems?


Agility in operations

It seems like Facebok is pretty agile in how it handles new features and roll outs. According to an article on the High Scalability site they actually do major releases every week. One of the things that struck me was this:

Be Innovative, Not Safe. Fear of failure often shuts down the organizational brain and makes it hide behind excessive rules and regulations. A technology company should have a bias towards action and innovation. Release software. Don’t stifle genius. Rely on your tools and processes to recover from problems.

This isn’t a solution to problems, but it is a pretty accurate description of what I want to achieve myself. Making a release shouldn’t be difficult or scary. This means that we need tools and methods that:

  • Enables us to be relatively certain that we don’t introduce any errors
  • Enables us to recover from a failure, because we will eventually fail

Tools like JUnit, Fitnesse, Selenium are all tools that allow us to verify the behaviour of our application. They help us verify that what we have done doesn’t introduce any errors. This should enable us to roll out quite easily, but I think in many projects one doesn’t trust the quality of the tests and you fear rolling out because you don’t have a good recovery plan.

I think we have a lot of tools available to us when it comes to writing tests, we just have to get better at using them, and eventually improving the tools. Where we seem to be missing is the part where we do good rollbacks. Maybe we don’t even need tools for that? I’d like to hear how you do it, and what tools you use or are missing.


Automate it all

When doing Agile development identifying and eliminating waste is a important practice. There is many things to eliminate, but one of the usual remedies is to automate a manual and error prone task. In my experience it is worth spending a lot of time automating tasks, not just because it saves time but because it gives you predictability.

Taking automation and predictability all the way would probably lead you to something like Continious Production that Paul Duvall has a post on. Johannes Brodwall also has some good perspectives on something similar.

It is sort of the holy grail of agile development, and would be something like what Jeff Sutherland said the are doing at Patientkeeper. They have deploy at the push of a button that enables them to deploy new versions to all their customers on a regular basis.

Spend time automating people. 🙂