A technically impeccable migration can be experienced as a step backwards if the network link does not keep up. Once the application stops sharing a building with the user, the network goes from invisible infrastructure to part of the experience.
What follows: why perception worsens, what to measure before moving, what requires judgement, and how the link is sized.
The pattern is recognisable. The migration finishes on time, the systems respond well in technical testing, and users still report that “it is slower than before”.
They are almost always right, and the problem is almost never in the cloud: it is in the path the data now travels between user and application.
Why perception changes
Before, the application and the user shared the local network. Latency was measured in microseconds and bandwidth was effectively unlimited for internal use.
Afterwards, every interaction crosses the organisation’s outbound link. That link was sized for browsing and email, not for the whole operation to pass through it.
On top of that, many older applications were designed assuming a fast network: they make many small calls rather than few large ones. That design was irrelevant on the local network and becomes decisive when each call costs latency.
What to measure before moving
Latency to the chosen region. Not the theoretical figure but the real one, measured from the sites where the users are. Geographic distance is a guide but not the decider: the internet provider’s route weighs as much or more.
Traffic volume per application. How much it actually transfers on a typical day. It is the figure that says whether the current link is enough or has to be widened before moving.
The application’s conversation pattern. How many calls it makes to complete one business operation. A chatty application suffers from latency far more than its data volume would suggest.
Dependencies left behind. If the migrated application keeps querying a database that stays in the data centre, every operation crosses the link twice. That round trip is the most common cause of degradation after a partial migration.
What requires judgement
The choice between going out over the internet and contracting a dedicated connection depends on how much predictability matters. The internet is cheaper and its performance varies; a dedicated connection costs more and delivers stable latency.
For internal workloads in constant use, stability usually justifies the cost. For occasional access or for scattered remote users, standing up a dedicated connection solves a problem those users do not have.
Redundancy has to be decided too. When the whole operation depends on the link, that link becomes a single point of failure, and it deserves the same treatment as any other critical component.
What changes with distributed work
When users work from several sites or from home, routing all traffic through the head office to exit from there adds a detour the cloud does not need.
The alternative is to allow direct egress to cloud services from each location, with the security controls applied along the path rather than at the office.
That is a network architecture change, not an adjustment, and it is worth planning alongside the migration rather than as a later correction, because it also affects where security policy is applied.
How the link is sized
Start from measured traffic, not from the number of users. Two organisations of the same size can have very different consumption profiles depending on which applications they use.
Consider the peak, not the average. A link sized to the average works well most of the day and saturates exactly when it is needed most, which is usually at close of business or the start of the day.
And allow for growth. Every workload migrated afterwards adds traffic to the same link, so sizing should contemplate the full migration plan and not only the first wave.
What has to exist first
Real latency and volume measurements from the user sites, an inventory of dependencies between applications, and clarity about the order of migration.
The second produces the most surprises. The map of what talks to what is rarely documented, and it is precisely what determines whether a phased migration will work or degrade.
What to do when it has already happened
If the migration is done and the perception is slowness, it is worth resisting the immediate reaction of widening the link. Sometimes that is the right answer and often it is expensive and insufficient.
The first step is to separate latency from saturation. If the link is far from its capacity and the experience is still poor, the problem is latency and application design, not bandwidth: widening will change nothing.
If instead the link saturates in specific windows, the diagnosis is capacity and it admits two paths: widen, or move traffic off the peak, starting with batch processes that can run overnight.
Why do users perceive slowness after migrating?
Because traffic that used to travel over the local network now crosses the outbound link, sized for browsing and email. Applications that make many small calls notice it most.
When is a dedicated connection justified?
When predictability matters: internal workloads in constant, sustained use. For occasional access or scattered users it usually solves a problem that does not exist.
What causes degradation in phased migrations?
Dependencies left behind. If the migrated application queries a database that stays in the data centre, every operation crosses the link twice.
Which figure should sizing be based on?
The measured peak, not the average, and contemplating the full migration plan. A link fitted to the average saturates exactly when it is needed most.
