How to Build an Office IT Relocation Runbook with ChatGPT

The short answer: Give the model your asset list, circuit order dates and the one immovable date you have to trade on, then ask it to sequence backwards from that morning rather than forwards from today. You get a defensible four-phase runbook in an afternoon. It will not know your ISP's real lead time or your landlord's rules.

Office moves get planned by whoever is standing closest to the problem — usually the office manager or ops lead, working from a spreadsheet the agent sent over, on which the entire IT portion is one line reading "IT — move computers." That line is between forty and two hundred discrete tasks, roughly a third of which have to happen weeks before anyone touches a desk.

A relocation runbook is a highly structured document, and structured documents are what language models are good at. Give one enough real detail about your environment and it produces a sequenced, dated task list with owners and dependencies in about the time the conversation takes. The limit is worth stating before the method rather than after: the runbook is the cheap part. Nothing generated in an afternoon changes the fact that on the Saturday in question, someone has to be physically present when the rack is opened.

What Actually Goes Wrong in an Office Move (It Is Rarely the Desks)

Furniture arrives; movers are good at moving. Ask anyone who has run a relocation what actually went wrong and the same short list repeats.

The circuit was not ready. A new fibre or leased line into a building that has never had one can take six to twelve weeks depending on the market and whether the riser needs work. It is the most common reason a move date slips, and it is purely a lead-time problem — nobody compresses it on the day.

Something depended on something nobody had written down. The warehouse label printer authenticates against a server being decommissioned. The finance system's licence is tied to a MAC address. Scan-to-folder points at a share about to change subnet. None of it is complicated; it is simply undocumented, and it surfaces at 09:00 on Monday.

One legacy box could not move the way everything else did. Almost every SME has one — old, important, unsupported, and last rebooted three years ago. It needs its own mini-project, identified in week one rather than on move weekend.

Access broke, not the network. Door badges, alarm codes, after-hours registration, and whose name is on the landlord's security list. Teams routinely arrive on move Saturday and cannot get onto the floor.

Day one had no support model. Everything technically worked and forty people still could not print, because the printers were installed but not deployed and the person who knew how was on a plane.

A generated runbook catches the first category unprompted, because lead times are general knowledge. The rest it catches only if you tell it.

The Inputs a Useful Runbook Needs Before You Prompt Anything

The difference between a runbook worth following and a generic checklist is entirely what you put in.

Circuit Lead Times, the Asset List, Dependencies, and the Immovable Dates

Five things, the same five every time.

The dates that cannot move. Lease start and end, the day the old space is handed back in contracted condition, and the first business morning people must be productive in the new one. Most moves have exactly one truly immovable date and several that only look fixed; the whole schedule derives from telling them apart.

The connectivity position. What is ordered, with whom, with what confirmed delivery date, and the fallback if it slips. If nothing is ordered yet, that is the runbook's first output.

The asset list, honestly. Workstations, monitors, printers and MFDs, phones, switches, firewall, access points, anything in a rack, and the physical servers you would rather not admit to. A rough RMM export is enough — completeness matters more than precision.

The dependency map. What talks to what, on-premises versus cloud, what has a fixed IP or hardware-bound licence, and what breaks when the public IP changes. This is the input people skip and the one that pays best.

The people constraints. Headcount by team, who cannot be offline Monday morning, who must sit together, and whether anyone is traveling during the move window.

Give these as plain text and tell the model explicitly to ask clarifying questions before producing anything. A model that asks eight questions first produces a materially better runbook than one that starts writing immediately — and the questions themselves are the ones a relocation project manager would have asked.

Structuring the Output — Pre-Move, Move Weekend, Day One, and the Two-Week Tail

Ask for four phases and say what belongs in each, or you get one long undifferentiated list.

Pre-move, from twelve weeks out. Everything with a lead time: circuits, procurement, licence transfers, vendor address changes, cabling and rack installation, the pre-move audit. Date these relative to the move rather than to today, so the schedule survives a slip.

Move weekend. Hour by hour, named owners, and a go or no-go checkpoint before the point of no return. The only phase timed in hours, and the only one where sequence genuinely matters.

Day one. Deliberately over-resourced: floor-walking support, a triage point, an escalation path, and a list of the twenty things most likely to be reported before 10:00.

The two-week tail. Old-space decommissioning, equipment returns, closing circuits so you stop paying for them, documentation updates, post-move review. Skipped more often than any other phase, and where the money quietly leaks — old circuits billing for months after nobody uses them is close to universal.

Ask for task, owner, phase, dependency and target date as structured text you can paste into a sheet. Then ask the question that gets far less use than it should: which tasks are on the critical path, and which three are most likely to slip?

A Worked Example: A 60-Person Office Move Sequenced Backwards From Monday Morning

A 60-person professional-services firm is moving between buildings in the same city. The old lease ends five weeks after the new one starts, and the immovable date is the Monday the company must be working from the new address. The comms room holds a firewall, two switches, a NAS, and one physical server running a practice-management application the vendor no longer actively develops.

Monday 09:00 is the fixed point. Working back: the network must be proven Sunday, so live and tested Saturday, so the circuit delivered and tested at least two weeks earlier — not the week before, because a failed circuit test needs recovery time. That one dependency chain sets the circuit order at roughly twelve weeks out, which is why connectivity is task one rather than a line item in the middle.

The legacy server gets its own track. It cannot be moved Saturday and tested Sunday like everything else, because if it does not come back up there is no fallback. The realistic options — a physical move a week early with a temporary link, a lift-and-shift to a cloud instance beforehand, or a longer communicated outage — are all week-one decisions. Treating it as a Saturday task is the mistake.

Workstations move in two waves, half Friday evening and half Saturday, so a problem found in the first does not apply to all 60. Models suggest this readily when asked for risk-reduction opportunities.

Day one is staffed at three times normal, one person on printing and one on everything else — printing accounts for a disproportionate share of day-one tickets.

The model produced a 90-task runbook with sensible dependencies and a defensible critical path in an afternoon. What it could not produce was the knowledge that the new building requires 48 hours' notice for goods-lift bookings and does not permit them on Sunday mornings — which moved four tasks and was found by someone reading the building handbook.

An AI-Generated Runbook vs a Relocation Partner's Project Plan vs Winging It

• Speed and cost to first draft — the generated runbook wins outright. An afternoon at no marginal cost, and you regenerate it when the date moves rather than reworking a spreadsheet by hand.
• Completeness of the generic categories — the generated runbook is strong. Lead times, standard phases and the tasks everyone forgets are well represented in general knowledge, and it does not get bored on task 70.
• Local and building-specific knowledge — the relocation partner wins decisively. Which carriers actually deliver on schedule in a district, which buildings have riser problems, how a landlord handles after-hours access. None of it is in any model, and it is most of the risk.
• Accountability on the day — the partner wins absolutely. A runbook does not carry a rack down a stairwell, answer the phone at 23:00 on Saturday, or get held to a service level.
• Adapting when something fails mid-move — the partner wins. Re-planning under time pressure with a van outside is judgement and experience, not document generation.
• Winging it — wins on effort alone, and a surprising number of SMEs do it. The failures are expensive precisely because they surface on a Monday morning with everyone watching.

These are not really alternatives. A generated runbook is how you arrive at the relocation conversation already knowing what you are buying and where your environment is unusual — a far better starting point than a blank form, and one that makes the professional engagement shorter and more focused.

The Items No Generic Checklist Will Include

Some categories are structurally invisible to a model.

Your provider's real lead time, as opposed to the published one. Quoted and actual delivery dates differ by market and by whether the riser is already provisioned. Only someone who has ordered circuits into that district recently knows the gap.

The landlord's rules. Goods-lift windows, permitted working hours, movers' insurance certificates, shared loading bays, after-hours notice periods. Every building differs and none of it is public.

Regulatory or contractual constraints on your data. If you hold client data under a specific obligation, moving a server across a boundary — or standing up a temporary link between two sites — is worth checking before rather than after.

Your one weird dependency. A model can prompt you to look, but it cannot know the production line's licence server is a desktop under a table in the corner.

Getting This Right — Asset and Floor-Plan Data, Downtime Risk, and When to Bring in IT

Three practical points before you paste anything into a chat window.

Treat the asset list as sensitive. A complete inventory of your systems, versions, IP ranges and dependencies is useful to you and extremely useful to someone attacking you. Use a business tier with contractual data-handling terms, generalise where detail adds nothing — "a firewall" rather than model and firmware — and keep the finished runbook access-controlled.

Be honest about the downtime you are actually buying. Every relocation plan contains an assumed outage window, usually understated because nobody wants to be the person who says the company might not work until Tuesday. State it, agree it with the business before the move, and plan the fallback. A generated runbook will happily assume everything works.

Decide early which parts you are not doing yourself. Structured cabling, rack installation, circuit coordination, the out-of-hours physical move and day-one floor support are the usual candidates — exactly the scope of Brocent's IT relocation services, covering pre-move planning through post-move support. Our AI+ support practice and managed IT support sit either side of the move itself. Brocent has delivered these across Asia since our founding in Beijing in 2007, with headquarters in Singapore and a Hong Kong office since 2016 — a delivered example is our Hong Kong telecom and media office relocation. The same phase-and-checkpoint pattern appears in generating an ERP go-live cutover runbook.

Frequently Asked Questions

How far ahead should the internet circuit be ordered?

Assume six to twelve weeks for a new fibre or leased line, and treat it as the constraint the schedule is built around rather than a task among others. A tower already provisioned for business tenants is faster than a converted industrial space needing riser work. Order before the fit-out design is finalised, confirm the date in writing, and plan a temporary fallback such as a bonded 5G service. It is the most common reason a move date slips.

What is a realistic downtime window for a 60-person office?

For a well-prepared move with the network already tested in the new space, Friday evening to Sunday evening with people productive Monday morning is achievable — because connectivity, cabling and wireless were proven days earlier, leaving only physical relocation. If the circuit is being tested for the first time on Saturday, you are not doing a two-day move, you are hoping for one. A legacy on-premises system usually needs a longer window of its own.

Does AI know local building or landlord requirements?

No, and this is the clearest boundary. Goods-lift rules, permitted working hours, movers' insurance requirements and after-hours access procedures are building-specific and published nowhere a model has seen. Get the building handbook and the property manager's contact in week one and read it against the draft runbook. Assume at least three tasks will move as a result.

What should be moved first?

In ordering terms, anything with a lead time — circuits, hardware, licence transfers. In physical terms, network infrastructure moves and is proven before end-user equipment; there is no point relocating 60 workstations into a space that cannot connect. Legacy systems with no rollback path get their own project, earlier and separately.

Who should own the go or no-go decision on move weekend?

One named person, agreed in writing beforehand, with a defined checkpoint and criteria — typically after network validation and before end-user equipment is disconnected at the old site. The common failure is a plan with no explicit point of no return, so that a problem at 16:00 on Saturday produces a group conversation instead of a decision. Write down what triggers a rollback and what the rollback involves.

Do we still need a project manager if we have a good runbook?

For a move under roughly thirty people with no on-premises infrastructure, a capable ops lead with a good runbook can often manage it. Above that — or with a comms room, a legacy system, or two sites in parallel — the coordination load during the weekend itself is the problem, not the plan. The runbook is what you hand the project manager, not what replaces them.

Where to Start

Do the pre-move audit before you generate anything. Walk the comms room, photograph the rack, export the asset register, and write down every system nobody wants to touch. That unglamorous hour decides whether the runbook is specific to your company or a well-written template. If the questions coming out of it are about lead times and who owns the weekend, that is the conversation worth having before the date is fixed: get in touch.