Harbour

A place to put the systems you cannot replace yet

1 interface However many systems sit behind it
No cutover Capabilities move one at a time
Reversible Route back to the old system per call

What it does

An integration layer that sits in front of legacy systems so new work can be built against one stable interface, and the old systems can be retired one at a time instead of all at once.

The plan is always to replace the legacy system. The reality is that it holds twenty years of rules nobody has written down, and a big-bang cutover is the riskiest thing the business could do.

Harbour puts one documented interface in front of whatever you have. New work builds against Harbour. Behind it, you move one capability at a time from the old system to the new, and nothing upstream notices. When the last capability has moved, the old system is switched off on an ordinary Tuesday.

Features

Per-capability routing

Send one operation to the new system and the rest to the old, then move the line when you are ready.

Reversible by design

Every route can be pointed back. A bad migration is a config change, not an incident.

The interface is documented

OpenAPI, generated from the running service, so it cannot drift from what is deployed.

Shadow traffic

Send real requests to the new implementation and compare responses before anyone depends on it.

Where it fits

Strangling a monolith

Where the replacement will take two years and the business cannot stop for it.

Post-acquisition

Two of everything, and a need to look like one company to customers immediately.

Opening up a closed system

When a vendor system has the data but not the API you need.

Specifications

Protocols
REST, GraphQL, SOAP, message queues
Deployment
Kubernetes, ECS, or plain VMs
Throughput
Tested to 12k requests/second per node
Observability
OpenTelemetry traces on every hop

See it on your own data

A walkthrough with the people who built it, not a sales deck.

Contact us