Consider this hypothetical move: a company with 38 staff signs a lease, plans the furniture and fixes a move date. Two weeks before Monday, someone asks who is arranging the internet. The ISP quotes a fibre installation lead time longer than the time left, the server cupboard turns out to have no ventilation, and the cabling contractor has not started because the interior work is unfinished. The move happens anyway, and the team spends the first week on mobile hotspots.
An office move can fail because essential tasks were left too late. This guide helps office owners, IT managers and facility teams sequence a migration, define acceptance criteria and prepare a usable rollback. It focuses on relocation and cutover; existing guides cover network design, budgets, audits and handover in greater depth.
What "network migration" actually covers
A network migration is moving a working IT environment from one site to another with minimal loss of service. It has five layers, and each has a different lead time:
| Layer | What it includes | Typical dependency |
|---|---|---|
| Connectivity | ISP circuits, public IPs, leased lines or broadband, backup link | ISP survey, permissions, installation lead time |
| Physical infrastructure | Cabling, racks, power, cooling, outlets | Interior works progress, civil/electrical readiness |
| Network equipment | Firewall, core/access switches, PoE, WiFi access points | Procurement, configuration, staging |
| Services | DNS, DHCP, VPN, printers, telephony, CCTV, access control, servers/NAS | Configuration, vendor support, dependencies |
| People and process | Cutover schedule, communication, rollback, support cover | Management sign-off |
Cutover means the moment live use shifts from the old environment to the new one. A rollback is the pre-agreed path back if the cutover fails. A parallel run means both sites remain usable for a defined period. These three terms drive most of the planning below.
Why the sequence matters
Several workstreams can run in parallel. ISP orders, interior readiness and equipment staging start early; they converge at a pre-cutover readiness gate. Installed WiFi needs power, switching and its uplinks before validation. Cabling certification applies to completed permanent links, not to the switches themselves. Coordinate pathways, rack space, power and interior access before terminating and testing links.
Phase 1: Survey and requirements (start as early as the lease is signed)
Before choosing any equipment, collect facts. Use the new site's floor plan and, if possible, a walk-through while interior work is still in progress, because that is when cable routes can still be changed.
Count what must connect. List staff workstations, shared printers, meeting-room displays and video-conferencing units, IP phones or an EPABX, CCTV cameras and recorders, access control controllers, WiFi access points, and any servers or NAS. Record which devices need PoE.
Inventory existing dependencies. For each service at the old site, note what it depends on: the public IP address, a VPN tunnel, a static route, a DHCP reservation, a printer IP, a licence tied to a MAC address. These are the items that break silently after a move.
Record the current internet design. Note the ISP, bandwidth, static IP details, any port forwarding, any allowlists at third parties (bank portals, cloud services, remote vendors) that contain your old public IP.
Identify rack-room conditions. Check location, lockable access, available electrical points on a dedicated circuit, ventilation or air-conditioning, floor loading and space for future growth. Decide whether the equipment goes in a wall-mount cabinet or a floor rack based on equipment depth and weight, mounting suitability, cable entry, cooling and future capacity; verify load limits. Rack layout and dressing are covered in our server rack dressing guide.
Define the business-critical window. Ask which functions cannot be offline and for how long: billing, order entry, a call line, CCTV recording. This sets the cutover design and the rollback trigger.
Phase 2: Connectivity first
Order the internet circuit as soon as the address is confirmed. Typical steps are a feasibility check at the new address, a site survey by the ISP, commercial approval, then installation. Each stage depends on the ISP and on building permissions, so ask for written lead-time estimates and treat them as estimates, not commitments.
Points to decide while ordering:
- Capacity. Size by simultaneous use, not headcount alone. Cloud applications, video calls and backups dominate. Nominal line speed is not usable throughput; measure after installation.
- Public addressing. A static public IP is often useful for fixed VPN peers, inbound services and third-party allowlists, but it is not universally mandatory. Some supported designs use dynamic DNS or outbound tunnels. Check for CGNAT, public address availability, routed blocks and handoff mode with the provider. Never assume a static address guarantees inbound access.
- A second link. If downtime is costly, order a second circuit from a different provider and, ideally, a different physical path. Failover design and its limits are covered in our dual ISP guide.
- Handoff. Ask what the ISP delivers (fibre media converter, ONT, Ethernet handoff) and what you must provide (power, rack space, patch cord).
- Notice on the old circuit. Check the old contract's notice period and relocation terms. Do not cancel until the new site is accepted.
DNS and addressing. List records and third-party systems that reference the old address. DNS TTL controls caching time; lowering it does not invalidate values already cached. As a planning recommendation, reduce controlled records at least one full previous TTL period before cutover, with margin. For an old TTL of 86,400 seconds (24 hours), reduce it at least 24 hours beforehand to, for example, 300 seconds (5 minutes), verify authoritative responses, then restore the normal value after stability. This is not a guarantee that every client changes in five minutes: application caches, existing sessions and negative caching may differ. Check relevant A and AAAA records, VPN peer settings and allowlists separately. [1]
Phase 3: Physical infrastructure
Cabling and rack work belong to the interior schedule. Give your contractor the outlet schedule, floor plan and ceiling/conduit constraints early.
Cable plan. Decide outlet counts per workstation, extra outlets for printers, access points, cameras and meeting rooms, and a spare allowance for growth. Choose the cable category based on current equipment and the planned life of the building; the choice and the standards context are covered in our structured cabling guide, and the applicable standard and edition should be confirmed for your project.
Labelling. Agree one scheme before installation: outlet ID at the faceplate matches the patch-panel port. Labelling done after the fact is a preventable source of long troubleshooting sessions.
Power and cooling. Provide dedicated, protected power for the rack, with UPS capacity sized from measured or rated equipment load, not guessed. For electrical design, earthing and protection, follow the applicable standards and have the work verified by the responsible electrical engineer. This article is not a substitute for that approval. Check both watt and VA ratings, manufacturer runtime at the load and battery condition. If measuring switch input watts, do not add its PoE endpoints again.
Certification. Have permanent links tested with a certification-grade tester against the chosen standard and category, not just a continuity or wiremap check. Continuity shows wires are connected; certification shows the link meets performance limits. Our Fluke testing guide covers this distinction. Agree the exact test limit, link/channel setup, adapters and calibration status, and retain native reports per labelled outlet. [2]
Phase 4: Staging and configuration
Configure equipment before it reaches the new site wherever possible. Staging in a workshop or at the old office reduces cutover-day risk.
- Firewall. Preserve a verified backup and use the old configuration as a reference. Import it only where the target vendor, model and firmware support migration; otherwise rebuild and validate the required behaviour. Plan the new IP scheme, VLANs for staff, guests, CCTV and servers, and NAT or port-forward rules for any published service. Guest isolation is covered in our secure guest WiFi guide, and general hardening in our firewall guide. VLANs need actual firewall/ACL enforcement; prove guest isolation with permitted and denied traffic tests.
- Switching. Prepare VLANs, trunk ports, PoE settings and management addresses. Confirm PoE budget against the connected devices; see our PoE power budget guide for the calculation.
- WiFi. Place access points using a predictive design and validate after installation; placement is covered in our WiFi access point guide. Do not copy the old office's AP count to a new floor plan.
- Servers, NAS, printers, telephony, CCTV. Document IP addresses and credentials in a secure location. Confirm vendors' support for relocation where licensing or warranty applies.
- Backups. Take application-consistent backups and verify representative restores before powering down equipment for transport. Keep an encrypted copy outside the transported hardware and record the last successful backup, recovery-time objective and acceptable data-loss window. A backup file without a proven recovery method leaves recovery uncertain.
Keep addressing deliberate. Overlapping routed subnets complicate ordinary site-to-site connectivity. Choose non-overlapping private ranges for a parallel run where practical, after checking remote users and partner networks. A vendor-supported NAT design can handle some overlap, but adds configuration and application constraints; it is not automatically available on every firewall. [3] Private ranges come from RFC 1918, which does not prescribe your VLAN design. [4]
Worked example
Illustrative example with assumptions. It is not an installed APYS project and the numbers are not measurements.
Assumptions
- 38 staff, one floor, new fit-out in progress
- 50 active cabled outlets: 38 desks + 4 AP drops + 2 printers + 6 cameras
- 15% growth allowance on those 50 outlets; phones share desk connectivity or are not separately cabled in this model
- Two ISP links ordered; a static IP on the primary
- Move over a weekend, with Monday as the first working day
Port count
Planned outlet capacity = 50 × 1.15 = 57.5, rounded up to 58. This is a growth allowance of eight whole outlets, not a measured future demand. For this model, reserve four additional copper switch ports for firewall, server/NVR or inter-switch connections: 58 + 4 = 62. The four-port allowance is explicit and illustrative; count actual connections, including any extra NAS, core or server ports, before ordering.
One 48-port plus one 24-port managed switch provides 72 nominal copper ports. Under the stated allowance, 72 − 62 = 10 ports remain beyond the growth plan. One 48-port switch cannot support even the 50 active outlets. Three 24-port patch panels provide 72 termination positions, accommodating the 58 planned outlet positions. Physical empty panel positions do not create cable outlets: specify whether all 58 links are installed now or whether eight remain future pathway capacity. If uplinks use independent SFP/SFP+ or dedicated stack ports, count those interfaces and optics separately; shared/combo or copper uplinks consume the corresponding endpoint capacity.
PoE check
Ten devices need PoE in this example: four access points and six cameras. With no actual models supplied, no certified power budget can be stated. For an illustrative allowance at the switch power-sourcing side, assume 25 W per AP and 12 W per camera: (4 × 25) + (6 × 12) = 172 W. A chosen 20% planning margin gives 172 × 1.20 = 206.4 W. Select sufficient compatible PoE ports and at least this budget only after checking actual maximum/startup demand, allocation method, per-port limits, cable losses and power-supply configuration. Typical endpoint consumption is different from power reserved by class or negotiation. [5] This allowance does not cover future PoE devices; recalculate their watts and port counts. See our PoE power budget guide.
Timeline (weeks relative to the move date, M)
| When | Task |
|---|---|
| M−8 | Site survey, requirements, ISP orders placed |
| M−6 | Cabling plan frozen, procurement started |
| M−5 | Cabling installation begins (subject to interior progress) |
| M−3 | Cabling certification and rack readiness gate; staging already underway |
| M−2 | Notify third parties, confirm tested ISP circuit; prepare DNS TTL reduction |
| M−1 | Pre-cutover test with a pilot group of devices |
| M weekend | Cutover |
| M+1 week | Hypercare, snag list, old-site circuit retained |
If the ISP lead time is longer than eight weeks, the whole plan moves, or a temporary link is arranged. That is exactly why connectivity is ordered first. The dates above are an illustrative schedule, not Pune ISP lead times or a delivery commitment. Lower each controlled DNS TTL based on its actual previous value; doing it two weeks early is optional, not a requirement.
Cutover sequence
Agree a last safe rollback time. If Monday operations begin at 09:00 and the rehearsed fallback takes six hours, a 07:00 Monday decision is already too late. Choose a deadline that leaves the measured recovery duration plus validation and contingency time.
A workable weekend sequence:
- Freeze and back up. Announce the freeze, take final backups, record the old site's configuration. Verify vendor contacts, authorised test accounts, transport inventory, equipment owners and the agreed decision deadline.
- Shut down and label. Power down in dependency order (end devices, servers, then network). Photograph rack connections before disconnecting.
- Transport. Move servers, NAS and network equipment carefully. Keep drives and any security tokens under supervision. Use suitable packaging, an asset check-out/check-in record and the manufacturer transport instructions. Confirm service dependencies and storage shutdown procedures with the application owner.
- Rebuild. Use an approved dependency-based startup sequence; an illustrative order is: power and UPS, firewall and ISP link, core switch, access switches, then servers and NAS, then end devices.
- Validate in layers. Link and PoE, then DHCP and DNS, then internet, then internal services, then applications.
- Update external references. Update DNS records, third-party allowlists and VPN peers for the new public IP. Prepare allowlist changes with owners before the weekend; do not assume third-party approval can be obtained during cutover.
- Go/no-go. Decide at a pre-agreed time against pre-agreed criteria. If the criteria are not met, execute the rollback.
Rollback design. Keeping the old circuit live is only one prerequisite. If its firewall, switches and servers have been transported, the old office is no longer a ready fallback. Either preserve or provide temporary equipment and accessible services for a parallel run, or budget the travel, reinstall, restore and testing time needed to return equipment. Document who can access the old premises. DNS reversal applies only to services that changed records; it does not restore transported hardware, live sessions or lost data. Define how new writes at the new site will be reconciled before reverting so that rollback does not silently discard transactions.
Common failure modes and troubleshooting sequence
| Symptom | Likely causes | First checks |
|---|---|---|
| No internet at new site | ISP provisioning incomplete, wrong handoff mode, wrong VLAN or WAN settings | WAN link, address, route and handoff settings; ISP-approved isolated test if required |
| Internet works, some sites fail | DNS, MTU, allowlist with old IP | Resolve names and test actual application access; check MTU and allowlists; ICMP failure alone is inconclusive |
| Devices don't get an address | DHCP scope or VLAN trunking | Check VLAN on the port, DHCP leases |
| Access points offline | PoE budget, VLAN, uplink | Port PoE status, switch log |
| One outlet dead | Patch not made, termination fault | Check patch panel, test with a certifier |
| VPN down | Changed public IP, overlapping subnets | Peer addresses, subnet conflicts |
| Printers or NAS unreachable | Static IP in old range | Confirm configured IP and gateway |
| Slow WiFi | Channel/power design, backhaul link speed | Survey, check AP uplink negotiation |
Order of investigation. Work from the bottom up: physical link, then addressing (DHCP), then name resolution (DNS), then routing and firewall, then application. Changing several things at once makes the fault harder to find.
Acceptance tests and evidence
Test after cutover, record the results, and keep them. What to test, and what to retain:
| Area | Test | Evidence to retain | Judge by |
|---|---|---|---|
| Cabling | Certification of every permanent link | Tester report files per link | Pass against the specified standard and category |
| Internet | Throughput and latency to a nearby server, measured at several times of day | Dated test records with method and tool | Meets the contracted service within agreed tolerance; note that measured values are not the nominal line speed |
| Failover (if two links) | Controlled primary-link failure and restoration in an agreed maintenance window | Time to recovery, what dropped | Design target met; record session disruption and failback behaviour |
| WiFi | Signal and throughput walk-test in every area | Heatmap or survey record | Meets the coverage and performance criteria set in the design |
| PoE | Device power-up on every PoE port in use | Switch PoE report, budget calculation | Compatible ports, maximum/startup allocation and total budget verified; cold-start test passes |
| Services | DHCP, DNS, printing, file access, VPN, telephony, CCTV recording | Test sheet signed by the owner of each service | Each critical workflow meets agreed acceptance criteria, signed by its owner |
| Security | Firewall rule review, guest isolation, admin access, default passwords | Restricted configuration export, rule review and actual allowed/denied-path tests | Agreed security policy enforced with authorised management access retained |
| Backup | Restore test | Restore log | Data restored successfully |
Handover checklist
Documentation
- As-built floor plan with outlet IDs
- Cable certification reports
- Rack layout and patch map
- IP plan and VLAN list
- Firewall and switch configuration backups, stored securely
- ISP details: circuit IDs, support contacts, public IP details
- Equipment list with serial numbers and warranty details
- Admin credentials transferred through an approved secure channel; shared accounts reviewed
Operations
- Backups running and a restore tested
- UPS runtime tested under realistic load
- Monitoring or alerting in place for internet, firewall and critical devices
- Snag list with owners and dates
- Old circuit and old-site equipment decommissioned only after sign-off
- DNS TTLs restored to normal values
FAQs
How early should we order internet for a new office?
As soon as the address is confirmed. Installation depends on the ISP's survey, approvals and building access, none of which you control. Ask for the lead time in writing and plan the move date around it.
Can we keep the same public IP when we move?
Only if the ISP can provide it at the new location, which depends on the provider and the service type. If it cannot, plan for changes to DNS, VPN peers and third-party allowlists.
Is a weekend enough for the cutover?
Only if the staging, cabling and ISP link are already complete and tested. The weekend should be for moving and validating, not for first-time building. If major items are still open, extend the window or run both sites in parallel.
What should we do with the old office network?
Keep it available until the new site is accepted and the rollback window has passed. Before decommissioning, wipe or securely handle any storage devices and remove sensitive configuration from equipment being returned or sold.
What if both sites use the same subnet?
A clean move may retain addressing, but ordinary routing and VPN connectivity between overlapping sites needs redesign or supported NAT. Prefer non-overlapping ranges for a parallel run and validate application paths.
Who verifies the electrical work?
The responsible electrical professional must apply the relevant local requirements. Network acceptance does not certify electrical or fire-safety compliance.
Worked rollback deadline: calculate backwards from business opening
Assume Monday operations must resume at 09:00. In this invented example the rehearsed fallback takes six hours, business validation takes one hour and the project reserves one hour of contingency. The latest rollback decision is 09:00 − 6 h − 1 h − 1 h = 01:00 Monday. A 03:00 decision is already two hours too late for this plan.
| Checkpoint | Required evidence | Decision owner |
|---|---|---|
| Before transporting equipment | Fallback hardware, old-site access, usable services and data recovery path exist. | Migration lead and service owners. |
| Before accepting new transactions | Write freeze/reconciliation procedure and acceptable data-loss window agreed. | Application/data owner. |
| By the calculated 01:00 rollback deadline | Required business workflows meet the pre-agreed criteria, or rollback starts. | Named go/no-go authority. |
| After a successful cutover | Backups, monitoring, new-site documentation and remaining snags checked. | Operations owner before old-site decommissioning. |
The six-hour duration must include the real fallback method. If it requires travel, unpacking, reinstallation or third-party assistance, those dependencies belong in the rehearsal. Retaining the old circuit without the old-site equipment and accessible data is not a completed fallback.
DNS reversal and data rollback are separate workstreams
Suppose a controlled DNS record had a 24-hour TTL and is reduced to five minutes at Friday 18:00. A resolver that cached the old answer just before the change can retain it until roughly Saturday 18:00 within that prior TTL. The new five-minute value does not retroactively shorten the old cached value. Plan the change from the previous TTL, verify authoritative answers and test relevant A/AAAA records and clients.
Reversing DNS does not undo new database writes or restore transported hardware. Before enabling production writes at the new site, define who can freeze them and how transactions are reconciled if returning to the old environment. Retain the last validated backup time, recovery result and application-owner decision. A tunnel showing “up”, a ping reply or a desktop login is not a substitute for the required business transaction.
Use the acceptance record and handover pack to preserve the final state, outstanding exceptions and support ownership.
Editorial review: 28 October 2026. Worked values are illustrative; no customer measurements or completed APYS recovery tests are implied.
Sources and Further Reading
- IETF RFC 1035: DNS TTL and caching
- Fluke Networks: Top 10 Cable Testing Mistakes
- Cisco: Overlapping Subnets in Secure Access
- IETF RFC 1918: Private IPv4 Address Allocation
- Cisco: PoE Configuration and Power Allocation
Reviewed 6 October 2026. Manufacturer examples explain mechanisms, not specifications for this hypothetical office. No actual device models, ISP contract, layout or migration measurements were supplied. Electrical requirements, equipment compatibility and project test limits must be confirmed by the responsible project team.
Planning an office move?
APYS Projects supports office networking, structured cabling, Cat6/Cat6A certification, WiFi, firewall and rack works. Share your new floor plan, device list, existing network details and target move date. Email Purchase@apysprojects.com, call +91 9921490342 or contact APYS Projects. Based in Wagholi, Pune, we serve projects across India.