Network Migrations & Upgrades

Every network eventually outgrows its architecture. We plan and execute migrations with the precision that live infrastructure demands — so your business stays online while your network moves forward.

The Most Dangerous Words in Networking: ‘We’ll Just Do It Live.”

Network migrations are among the highest-risk projects an engineering team undertakes. The infrastructure being changed is usually business-critical. The dependencies are often undocumented, discovered only mid-migration. The maintenance window is shorter than you’d like. And the rollback procedure — if there is one — has never been tested.

At AMROTS, we approach migrations the way a surgeon approaches an operation: with exhaustive preparation, a clear procedure, a practiced hand, and contingencies for everything that might go wrong. The preparation phase of a migration is never rushed, because the time invested in thorough discovery and planning is the primary thing that separates a clean cutover from a 3am incident with the whole business watching.

We’ve planned and executed migrations across carrier backbones, enterprise data centres, and campus networks — platform replacements, routing protocol migrations, data centre re-architectures, and hardware refresh cycles. We know where the risk concentrates, and we know how to manage it

Platform migrations — Cisco to Juniper, legacy to Arista, end-of-life hardware replacements

Routing protocol migrations — OSPF to IS-IS, legacy MPLS to Segment Routing, RIP to anything modern

Data centre re-architecture — spanning-tree to EVPN-VXLAN spine-leaf migrations

WAN migrations — legacy MPLS to SD-WAN, circuit provider changes, BGP re-numbering

OS and software upgrades — JunOS, IOS-XR, EOS version upgrades with minimal service disruption

IP address re-numbering and AS number migrations

Consolidation migrations — merging multiple networks post-acquisition or restructuring

Full cutover planning with documented rollback procedures for every step

Plan My Migration

For Consultation: +374 00 000 000

Why Network Migrations Fail and How We Prevent It.

Most network migration failures aren’t caused by technical incompetence. They’re caused by the same five things, over and over. We’ve seen them all — and we plan against every one of them from day one.

Preparation Is Everything

The ratio of planning to execution in a well-run migration is usually at least 3:1 — and often higher. The engineers who’ve been doing this long enough know that the migration itself is the easy part. The hard part is knowing everything that could go wrong before you start.

Rollback Is Not Optional

Every step in every cutover plan we produce has a tested, documented rollback procedure. Not a theoretical one — an actual procedure that we’ve thought through and know will work under pressure at 2am with the business watching. If a step doesn’t have a clean rollback, we redesign the approach until it does.

We Stay Until It’s Done

We don’t hand over a cutover plan and wish you luck. We work alongside your team through the migration window — from the first change to the final verification check. If something unexpected happens, we’re there to diagnose it, adapt, and resolve it.

Platform & Hardware Migrations

End-of-life hardware replacements, vendor platform changes, and technology refresh cycles — we plan and execute the full migration from current-state documentation through to post-cutover verification. Every migration is designed to maintain service continuity with zero unplanned downtime.

Routing Protocol & Architecture Migrations

Migrating from one routing protocol or architecture to another on a live network is one of the most complex things you can do — OSPF to IS-IS, legacy MPLS to Segment Routing, spanning-tree to EVPN-VXLAN. We design migration sequences that allow both the old and new architectures to coexist during transition, enabling staged cutovers with clean rollback at every step.

Network Consolidation & Re-numbering

Post-acquisition network mergers, IP re-numbering projects, and AS number migrations are complex, lengthy, and highly disruptive if poorly planned. We bring the structured project management and technical depth needed to plan and execute consolidation migrations cleanly — resolving conflicts, managing dependencies, and keeping the business running throughout.

From beginning to end

How We Plan and Execute Network Migrations.

Through experienced startup consultants who understand the isolated tasks necessary, a client can rely on a professional to manage a critical step in the early stages and focus on other items that need attention.

Discovery & Dependency Mapping

Before a single line of the cutover plan is written, we invest heavily in understanding exactly what exists today. We document the current-state architecture in full — every device, every interface, every routing policy, every circuit, every dependency that touches the scope of the migration. We review existing documentation critically, validate it against device configurations, and fill in the gaps ourselves.

This phase is never rushed. An undiscovered dependency discovered mid-cutover is the most common cause of migration failures, and thorough discovery is the primary mitigation. We ask the questions others skip — 'what else uses this device?', 'what breaks if this VLAN disappears?', 'has anyone tested what happens when this link goes down?' — because those are the questions that matter.

Cutover Plan Design & Lab Validation

With a complete picture of the current state and target state, we write the cutover plan — a step-by-step procedure covering every change, every verification check, every rollback procedure, and every go/no-go decision point. Nothing is left to improvisation.

Where possible, we validate the migration sequence in a lab environment — building a representative topology and running through the cutover to verify sequencing, test rollback procedures, and identify any issues before production. For complex migrations, this lab validation phase is non-negotiable.

Execution, Verification & Handover

On cutover night, we work methodically through the plan — executing each step, verifying the expected outcome, and only proceeding when verification passes. We communicate clearly with your team throughout, calling go/no-go decision points explicitly and never proceeding when something doesn't look right.

Post-migration, we conduct structured verification — checking every critical traffic flow, BGP session, routing table, and service before declaring the migration complete. Full as-built documentation is updated to reflect the post-migration state, and we provide a post-migration report covering what was done, what was found, and any recommendations for follow-on work

preparation to execution

Our Migration Process

We provide the best services, ensuring your outstanding growth

Discovery & Current State Documentation

We document the existing network comprehensively — topology, configurations, routing policies, traffic flows, circuits, and all dependencies within scope. We validate existing documentation against reality and identify every dependency that could affect the migration. This step is never abbreviated.

Target State Design & Cutover Planning

We design the target state architecture and produce a detailed cutover plan — step-by-step procedures, verification checks, rollback procedures, and go/no-go decision points for every stage. The plan is reviewed with your team and agreed before any changes are made.

Lab Validation & Rehearsal

Where possible, the migration sequence is validated in a lab environment — running through the cutover procedure, testing rollback steps, and verifying sequencing. For complex or high-risk migrations, a full rehearsal in the lab is strongly recommended and something we actively encourage.

Cutover Execution & Post-Migration Verification

We execute the migration methodically alongside your team — following the agreed plan, verifying at each step, and maintaining discipline around go/no-go decisions. Post-migration structured verification confirms all services are operating correctly before the window closes. Full updated documentation is delivered on completion.

Got a Migration Coming Up? Don’t wait, let’s Talk Before You Start Planning.

The earlier we’re involved in a migration, the better the outcome. Discovery takes time — and the things we find during discovery shape everything that follows.

Hovsep Emin 130/1
Yerevan, Armenia 0051

Consulting: +374 00 000 000
Corporate: +374 00 000 000

Frequently Asked Questions

Some frequently asked questions about the service that you may have questions about

How far in advance should we engage you for a migration project?

As early as possible — ideally before internal planning has progressed too far. The discovery phase shapes everything: the cutover plan, the maintenance window requirements, the rollback strategy, and the risk assessment. Bringing us in late means compressing the phase that matters most. For large or complex migrations, we'd want at least 4–8 weeks of preparation before the cutover window.

Can you migrate our network without any downtime?

For many migrations, yes — or close to it. The key is designing a migration sequence that allows the old and new architectures to coexist during the transition, enabling traffic to be moved progressively rather than in a single cutover. For others, a maintenance window is unavoidable, but we minimise the window duration through thorough preparation and staged execution. We'll give you an honest assessment of what's achievable for your specific migration.

What if something goes wrong during the cutover?

Every step in our cutover plans has a documented rollback procedure. If something doesn't go as expected, we assess, decide, and either resolve the issue or execute the rollback — clearly and calmly. We've been in enough difficult migration windows to know that unexpected things happen, and that what matters is how you respond to them. We don't panic, we don't improvise carelessly, and we don't proceed when the situation isn't clear.

Do you work alongside our internal team during migrations?

Yes — always. We work collaboratively with your internal team throughout the migration, providing the senior engineering expertise and structured planning while your team maintains ownership and visibility. Knowledge transfer is a natural part of the process — your team understands what's been done and why, and is fully capable of operating the post-migration environment.

Can you help with OS upgrade programmes across a large device fleet?

Yes — upgrade programmes across large device fleets require careful planning around feature parity, behaviour changes between versions, sequencing (upgrade access layer before distribution, or vice versa?), and rollback options. We plan and execute these programmes systematically, typically using automation tooling to manage the upgrade process and verify outcomes at scale.

What documentation do you produce?

Every migration engagement produces updated as-built documentation reflecting the post-migration state — topology diagrams, device configurations, routing policy documentation, and operational runbooks. We also produce a post-migration report covering what was done, what was found during the process, and any recommendations for follow-on work. The documentation is always accurate — we update it based on what was actually deployed, not what was originally planned.

See More & Ask Us Questions

Amrots — Your network, engineered right.