Sequencing an office move

An office move is one of the few IT projects with a date that genuinely cannot slip. People arrive at the new building on Monday whether or not the network is working.

Keeping the disruption to a weekend is achievable, and it depends almost entirely on what was ordered early enough. The technical work at the new site is straightforward. The lead times are not.

Twelve weeks out: order the circuits

Connectivity is the long pole and it is outside your control. Fibre installation can take two to three months, sometimes longer if civil works are needed. Everything else can be compressed; this cannot.

Order as soon as the lease is signed:

• Primary circuit, with the installation date confirmed in writing.
• Secondary circuit, ideally from a different provider and entering the building by a different route. Ask specifically whether the two share infrastructure: providers frequently resell the same physical fibre, and diverse contracts over a single duct is not diversity.
• A temporary fallback. A mobile broadband router with a decent data allowance costs very little and has saved a great many move weekends. Order it regardless of how confident the provider sounds.

Confirm the demarcation point, where the circuit physically terminates in the building, and check it is where you want your comms room. Moving it later is expensive.

Ten weeks out: survey the building

Visit with someone who knows what to look for. What to establish:

• The comms room. Power, including whether the supply is adequate and whether there is a dedicated circuit. Cooling, which is the thing most often missing. Physical security. Enough space for the racks you need.
• Existing cabling, if any. Test it rather than trusting the landlord's description. Category and condition both matter, and "recently refurbished" often means the walls were painted.
• Where the access points need to go, based on the floor plan and the construction. Solid walls, glass partitions and metal shelving all affect coverage.
• What the landlord controls. Some buildings restrict who may work in risers, when work may happen, and which providers may install. Find out before scheduling anything.

Eight weeks out: order equipment and book the cabling

Hardware lead times vary and have been unpredictable in recent years. Order switches, firewalls, access points and anything else with a lead time now.

Book the structured cabling work. Cablers get booked up, and the work must complete before equipment installation, which must complete before testing, which must complete before the move.

Six weeks out: plan the cutover in detail

Decide what moves and what is replaced. Anything old enough to be near replacement is usually better replaced than moved. You avoid the risk of it not surviving the journey and you avoid moving something you will replace shortly anyway.

Write the cutover sequence. The order that works:

1. Circuits live and tested at the new site, well before the move weekend. Not the day before.
2. Core network built and tested: switches, firewall, wireless, with connectivity to your cloud services and any remaining data centre confirmed.
3. Servers and any on-premises infrastructure, if applicable.
4. Printers and shared devices.
5. User equipment last.

Each stage should be verifiable before the next begins.

Four weeks out: DNS, and tell people

Lower DNS time-to-live values on anything whose address will change. Do this four weeks out so that caches everywhere have expired by the time you cut over. Restore normal values afterwards.

Communicate the plan. What people should do with their equipment, when they will lose access, what to expect on the first morning, and how to get help. Confusion on day one generates a volume of tickets that is entirely avoidable.

Two weeks out: test everything at the new site

The new site should be fully working before anyone moves. Test with real devices and real users, not just link lights:

• Connect a laptop and reach every business-critical service.
• Test wireless coverage by walking the floor, not by looking at a heat map prediction.
• Make and receive calls if telephony is changing.
• Print.
• Confirm remote access works from outside.
• Verify monitoring is reporting from the new site.

Anything found now is fixed on a Tuesday. The same thing found on move weekend is fixed under pressure.

The move weekend

Friday evening: final backups verified. Users shut down and label equipment. Old site equipment decommissioned in a documented order.

Saturday: equipment installed at the new site. Servers and infrastructure first, then user equipment. Test as you go rather than at the end.

Sunday: full testing with a small group of real users doing real work. This is the step most often skipped and the one that catches what infrastructure testing misses.

Sunday evening: decision point. If something significant is broken, you still have the fallback options: the mobile connection, or in the worst case telling people to work remotely on Monday. Making that call on Sunday evening is far better than discovering it at nine on Monday.

The first week

Have more support on site than seems necessary, for the whole week rather than the first morning. The volume of small problems (a printer not mapped, a desk port not patched, wireless weak in one corner) is high and each is quick.

Keep a list of everything reported. It is the snag list, and working through it in the first fortnight is what determines whether people remember the move as smooth.

Do not release the old site early

Keep the old site's connectivity for two to four weeks after the move if the contract allows. The cost is small and it is the only insurance against a serious problem at the new building.

Before cancelling, confirm nothing is still connecting to the old site, by measuring rather than by asking. There is almost always one forgotten integration.