Add QS-WAN to the network you already have
Nobody wants to replace equipment that works, and a project that opens with “first we swap the router” does not survive the first meeting. The real question is narrower and much more useful: what has to change, and what can be left alone.
The situation
There is a network. It was built over years, by people who mostly no longer work there, and it does its job. There is a firewall somebody trusts, switches nobody wants to touch, and at least one box whose configuration exists only in the head of a contractor.
Into this arrives a requirement, usually from outside: a regulator, a customer questionnaire, an insurer, or a board that read something. And the honest internal answer is that nobody wants to find out what breaks.
Why the usual answers do not fit
Rip and replace is the vendor’s favourite and the reason most of these projects never start. The cost is not the equipment, it is the weekend and the risk.
A parallel network avoids the risk by doubling the estate, and then you are running two of everything and reconciling them forever.
Doing nothing is what usually happens, and the requirement comes back next year larger.
One new box in the diagram. Everything else stays.
The gateway goes in next to the equipment you already have. One new box in the diagram; everything else stays.
The gateway sits next to the equipment you already have. Your firewall stays, your switches stay, your addressing stays. The gateway takes on the network’s identity, policy and encryption, and speaks to what is already there rather than replacing it.
It runs where it fits.
On hardware you already own, on a box we ship you configured, or hosted by us. That choice is usually decided by whether the network is allowed to touch the public internet at all.
The existing equipment keeps its job.
This is a layer, not a replacement. The phrase the founder uses is that evolving does not mean starting from zero, it means adding the right layer.
It connects to what you already run.
Identity from your directory, events to your existing security tooling, and the cloud networks you already have.
This is usually the situation when
- You have a network already, which is very nearly everybody.
- The kit in the rack works and the budget to replace it does not exist.
- You need to be able to describe the change to someone who was not in the room.
What your people see
The change is invisible to almost everybody. The person in accounts does not learn a new tool, does not get a new password, and does not get a migration email.
That is deliberate, and it is the reason these projects succeed or fail. About one per cent of an organisation opens a console. The other ninety-nine per cent open an app, and if the change reaches them at all, it reaches them as an app that was already there.
What we are not going to pretend
We do not know how long your integration takes. Anybody who quotes you a number without seeing the network is guessing, and you will hold them to it.
What we can tell you is which questions decide it: how many sites, whether the network may reach the internet, and whether identity already lives somewhere central. Bring those three answers to a call and the estimate is real.
What it takes, and what it leaves alone
One gateway in the path. Every subscription starts at three gateways.
One new box in the network diagram, and the access rules that go with it.
The router. The switches. The VLANs. The servers. None of it moves.
The features this use case relies on
Talk to a cybersecurity specialist
The people who answer are the ones who build the product.
NEWSLETTER
Get weekly tips, product news and early access, straight to your inbox.