Office Relocation as an Ops Project: Runbooks, Rollback Plans, and Zero-Downtime Moves

Engineering teams that would never push a config change to production without review will happily move their entire company to a new building on the strength of a shared spreadsheet and a group chat. Then the first Monday in the new office arrives: the ISP install slipped two weeks, the badge system doesn't talk to the identity provider, on-call is paging someone whose desk is in a moving box, and the conference room where the incident bridge usually happens no longer exists.

An office move is quite literally a change to production: your network edge, your physical security, your on-call coverage, and the workspaces your responders depend on all change at once, on a fixed date, with real dependencies on third parties you don't control. That description should sound familiar, and so should the remedy, which is to treat the move the way you treat any high-risk change, with a runbook, a rollback plan, a staged cutover, and a postmortem.

The Uptime Institute's 2025 outage analysis puts numbers on what that risk looks like: it found that 54% of organizations' most recent significant outages cost more than $100,000, one in five cost more than $1 million, and staff failing to follow procedures grew as a cause of outages year over year. A move compresses months of unusual, undocumented, one-off procedures into a single weekend. If procedure failure causes outages during normal operations, a procedure-free relocation is asking for one.

Start with discovery, not with boxes

Before anything gets scheduled, inventory what actually depends on the current office. Teams are consistently surprised by this list. The obvious items: circuits, firewalls, wireless, printers, meeting room AV. The less obvious ones: an IP allowlist at a client or payment provider that pins your office's static address, a license server humming in a closet nobody has opened since 2022, the direct fiber run a trading or media team quietly relies on, badge and camera systems with their own network, and the physical desk setup your on-call rotation assumes exists.

Every one of these is a dependency with a migration path, an owner, and a failure mode, and all of them belong in a written inventory. That document is the skeleton of your runbook, and producing it typically takes a few hours of asking around plus one unsettling afternoon with a switch closet.

The runbook

A relocation runbook looks like any other: ordered steps, owners, timestamps, verification checks, and a communication plan. A few move-specific rules are worth stealing.

Sequence around lead times, not preferences. ISP installs at a new address routinely take 30 to 90 days, and in older buildings, longer. Circuit delivery is your critical path; order it the day the lease is signed and schedule everything else behind it. The same goes for building riser access, which requires landlord approval that does not move at engineering speed.

Define verification for every step. "Network is up" is not a check. "A laptop on the new office wireless can reach the VPN, the internal wiki, and the video bridge, and a badge opens the server room" is a check. Steps without verification criteria are where the Uptime Institute's procedure-failure statistic comes to visit.

Name a move commander. One person holds the runbook during cutover weekend, the same way an incident commander holds a sev1. Decisions route through them. Group-chat democracy is how you end up with two teams unplugging the same rack.

Rollback means keeping the old office alive

Rollback for a physical move sounds absurd until you price the alternative. The cleanest version is a lease overlap: keep the old space for 30 to 60 days past the target cutover. If the new building's circuit slips or the wireless can't handle load, people work from the old office while you fix it, and the business notices nothing.

Overlap costs a month or two of double rent. Compare that to the outage math above, plus a week of a hundred people camping on hotspots, and it prices out as cheap insurance. If a full overlap isn't possible, define a degraded rollback: which 20 people go back, where the on-call bench sits, which functions must have desks on day one and which can absorb a week of remote work.

The other half of rollback is not burning bridges early. Don't cancel the old circuits on move day; run both until the new site has survived a full business week. It's the same reason you leave the old DNS record with a low TTL instead of deleting it the moment the new one resolves.

Zero-downtime tactics

Nobody actually needs the whole company to teleport on one weekend, so move in waves: infrastructure first, then a pilot group of volunteers who work from the new office for a week and file every broken thing they find, then everyone else. The pilot week is your canary deploy, and it will catch the kind of problem no site survey does, like the wireless dead zone exactly where the support team sits.

Protect on-call explicitly. Publish where responders sit during each phase of the move, confirm the incident bridge works from both sites, and consider freezing risky production changes for the cutover week. You don't want your first sev1 in the new building to start while the monitors are still in bubble wrap.

Site selection is capacity planning

Most of what goes wrong in a move is decided before the lease is signed, which makes building selection as much an engineering concern as a facilities one. Carrier diversity in the building, existing fiber, riser access, server room power and cooling, and realistic space for growth all belong in the evaluation next to rent.

That means engineering should see the shortlist early, while there still is a shortlist. In San Francisco, tech teams tend to concentrate in a handful of neighborhoods, and the concentration is operationally rational: a building that has hosted startups for twenty years usually comes with the fiber, the riser agreements, and a landlord already comfortable with server room buildouts. An architecturally charming building in a district that has never hosted a tech tenant can cost you a quarter of delays for the same rent.

South Beach fits that profile as well as anywhere in the city. It runs along the waterfront between the Financial District and Mission Bay, sits a short walk from the Caltrain terminal for anyone commuting up the Peninsula, and its building stock grew up around tech tenants. If your shortlist points that direction, you can review the current offices for rent in South Beach on Tandem Space, filter to suites that match your headcount, and send your network lead the top three addresses to check for carrier presence before anyone tours anything. Ten minutes of that beats discovering after signing that your building's only provider is a DSL reseller.

Close it out like an incident

When the dust settles, run the postmortem. What slipped, what the runbook missed, which vendor lead times were fiction. File the runbook itself somewhere findable, because companies that move once tend to move again in three to five years, and the next team will otherwise start from a blank spreadsheet and a group chat.

The best possible outcome is that nobody outside the company could tell it happened.