Keeping Older Systems Running While the Rest Moves

Nearly every business we work with has one. A production planning system written a long time ago by somebody who has retired. A stock control application from a vendor who stopped issuing updates years back. A database with two decades of history in it that three departments query directly through a spreadsheet.

These systems are difficult precisely because they work. They do exactly what the business needs, everyone knows their quirks, and the risk of replacing them is real while the benefit is theoretical. So the replacement gets proposed every couple of years and deferred every couple of years, which is a rational decision each time it is made.

Meanwhile the rest of the estate moves. Email went to a subscription, files followed, the new applications were built on rented infrastructure, and now one system sits in a rack in the office holding the whole arrangement in place.

That is hybrid, and it is a perfectly reasonable place to be. It only causes trouble when nobody designed it and nobody owns the question of how it ends.

The most useful rule for splitting an estate is to cut where the least conversation happens. Two systems that exchange a file once a night can live in different places without anybody noticing. Two systems that exchange thousands of small messages an hour will suffer every time you separate them, and no amount of bandwidth fixes it, because the problem is the round trip rather than the volume.

So map what talks to what before deciding anything. Network flow data will tell you honestly, and it usually contradicts the architecture diagram. Expect to find a dependency nobody mentioned: a reporting tool, a scheduled job, an integration built by a contractor for a project that ended.

Then group the systems that must travel together. The old application and the database it queries constantly belong on the same side. The reporting layer that reads once an hour can sit on either. Anything that only touches the old system through a file drop or a nightly extract is free to move.

Write the boundary down as a list of systems and the specific traffic that crosses it. That list becomes the design for the connection, the security rules, and the monitoring, and it is far more useful than a diagram with a cloud shape on one side.

The connection itself is either an encrypted tunnel over your normal internet connection or a dedicated private circuit from a carrier. The tunnel is quick to set up, cheap and adequate for a great deal of work. The private circuit costs more, takes weeks to provision, and gives you consistent performance rather than whatever the internet is doing that afternoon.

Start with the tunnel unless you already know the traffic is heavy or timing sensitive. You can move to a circuit later, and having run the tunnel for a few months gives you actual measurements to size it with. What you should not do is run production on a single tunnel with no second path, because that link becomes a way for both halves of your business to fail at once.

Name resolution is the part that consumes the most time and the least glory. Both sides need to be able to find things on the other by name, which means forwarding rules in both directions and a decision about which side owns which zone. When a hybrid setup misbehaves in the first month, this is the cause more often than anything else.

Then the ordinary hygiene that becomes important once two environments are involved. One identity source rather than two, with the older systems joined to it if they can be. Clocks synchronised from the same reference, because certificate validation and log correlation both depend on it. And certificates that are trusted on both sides, issued from somewhere that will still exist next year.

This is the decision that shapes everything else. When a new system in the cloud needs data that lives in the old one, it can either ask across the link every time, or work from a copy that gets refreshed on a schedule.

Asking across the link keeps the data current and couples the two systems tightly. The new system now depends on the old one being up, on the link being up, and on the old database being fast enough to serve an additional workload it was never sized for. Plenty of legacy databases are one enthusiastic integration away from being slow for the people who use them directly.

A copy is looser and staler. Extract on a schedule, load into something in the cloud, and let the new systems query that. The new work no longer depends on the old system's availability or performance, and the cost is that the data is as old as the last extract. For reporting, planning and analysis that is usually fine and occasionally an improvement.

The middle path is worth naming because it works well in practice. Keep the old system as the place records are written, copy changes out continuously or frequently into a store shaped for reading, and point everything new at the copy. Writes stay in one place with one set of rules, and the read load leaves the old machine alone.

File shares over the link are the classic. A shared drive that felt instant across the office is painful across a wide area connection, because the protocol was designed for a corridor. Users describe it as everything being slow, which sends the investigation to the wrong place for a week.

Batch jobs stretch. A nightly process that read from a local database and finished before anyone arrived now reads across a link, and the round trips multiply until it is still running at nine in the morning. The fix is usually to move the job to the same side as the data rather than to make the link faster.

Old clients time out. Software written when the network was local often has short timeouts and no retry logic, so the occasional slow response that a modern application would absorb becomes a visible error. Sometimes this is configurable and sometimes it is compiled in, which is worth checking before committing to a design that separates them.

And the link becomes a single point of failure with a very wide blast radius. When it goes down, the failure does not look like a network fault. It looks like six unrelated applications breaking in confusing ways, which is a hard thing to diagnose at speed unless you have monitored the link itself and alerted on it directly.

The tempting shortcut is to route everything between the two environments and be done with it. It gets the project moving, and it also means anything that gets into the cloud environment has a clear path to the old systems, which are the ones least able to defend themselves.

Allow only the traffic on your list, in the direction it actually flows, and review the rules when the project ends rather than leaving the temporary wide rule in place for ever. Most of the hybrid setups we inherit have exactly one rule of that kind, added during testing, still there years later.

Old systems often cannot take modern authentication, which is a real constraint rather than an excuse. Where an application will only accept an old protocol or a shared password, put the controls around it instead: restrict which machines can reach it, put a gateway in front where possible, log every connection, and be strict about who holds the credentials.

Log both sides into the same place. Half your evidence sitting on a server in the office and the other half in a cloud platform makes an investigation twice as slow, and investigations are always conducted in a hurry.

It is meant to be temporary. The old system stays for eighteen months while the replacement is scoped. Then the replacement slips, a new integration gets built onto the old side because that is where the data is, and another team connects to it because the connection already exists.

The budget line disappears first. Migration funding ends when the project closes, so the remaining work has no money attached to it and joins the queue behind everything that does. Then the people move on, and the knowledge of why the boundary sits where it does leaves with them.

The tell is when new things start being built against the old side. Each of those is a rational local decision and each one adds to what has to move later. After a few years the interim arrangement has more dependencies than the original system did, and the migration everyone still describes as pending has quietly got harder every year.

Nobody decides this. It is the default outcome whenever a temporary arrangement has no owner and no end condition, and most of them have neither.

A date in a plan does not survive contact with two years of other priorities. What works better is a written trigger: the condition that forces the decision back onto the table. When the vendor stops supporting this version. When the hardware maintenance contract ends. When the data volume passes a point the current machine cannot handle. When the last person who understands it retires.

Give the arrangement an owner and put a review in the calendar once a year, in the same meeting where the rest of the technology plan is discussed. The review asks three things: has any trigger fired, what has been added to the old side since last year, and does the original reason for keeping it still hold.

Set a rule about new work. Nothing new gets built on the old side unless somebody senior agrees in writing. It sounds bureaucratic and it is the single most effective control available, because it stops the pile growing while you decide what to do about it.

And keep the exit costed. A rough estimate of what replacing the system would take, refreshed each year, turns an uncomfortable conversation into a budget item. Most old systems survive because nobody ever put a number next to the replacement that a director could act on.