Most multi-location businesses approach a GHL migration the same way. They build everything, then flip the switch everywhere at once. That’s how you multiply your problems by five.
The right sequence is different. One location first. Prove the system. Then roll.
Here’s how I sequence it — based on a live migration across 5 locations in 3 states.
The Setup
Five locations. Three states. Each with its own staff, branding, and intake paths. Coming off Monday.com and a tangle of disconnected tools.
Each location would get its own GHL sub-account — same architecture, location-specific execution. Own pipeline. Own email config. Own staff access. Own branding in templates.
You don’t want to discover an intake routing edge case after it’s been misconfiguring leads across all five locations for two weeks.
Picking the Pilot Location
The instinct is to start with the smallest, simplest one — least risk if something breaks. That’s backwards.
Start with the highest-volume, most complex location. If it works there, it works everywhere.
The pilot location had 3,200+ leads — more than any other site. It had all three intake paths active and a history of edge cases. That made it the right choice.
| Selection Criteria | Why It Matters |
|---|---|
| Highest lead volume | More data means edge cases surface faster |
| All intake paths active | Tests the full routing configuration |
| Known complexity | Stress-tests the system before rollout |
| Cooperative staff | Faster feedback loop on what breaks |
The 7-Phase Build
Audit
Map every tool touching the lead funnel. Identify what GHL replaces, what stays, what retires.
Sub-account Architecture
Create the pilot sub-account. Set pipeline stages, exit paths, and all custom fields. No automations yet.
Intake Routing
Connect all intake paths: API webhook, web form, walk-in/phone. Each routes to the correct stage with correct tags.
Automations & Workflows
Build stage-change triggers, follow-up sequences, no-activity timers, appointment workflows. Timezone-aware from day one.
Integrations & Data Migration
Connect external APIs, migrate historical leads, validate data integrity. Test every integration end-to-end.
Pilot Launch
Go live at the pilot location. Staff trained. Intake paths live. Monitor for edge cases in real-use conditions.
Sequential Rollout
Remaining locations deploy the proven system with localized customization. One at a time.
What Actually Breaks in the Pilot
Every pilot surfaces something. That’s the point.
Intake routing edge cases. Walk-in leads entered without a source field — the automation expected a value and silently miscategorized the contact. Caught in week one.
Timezone-specific triggers. No-activity timers fired at the wrong local time. A 24-hour follow-up was sending at 2am. One config change — but needed per location.
Location branding in templates. Email templates had the pilot location’s branding hardcoded — not pulled from a dynamic field. Would have sent the wrong logo to every other site.
None of these are catastrophic in isolation. Multiplied across five locations running in parallel — they become expensive to unwind.
Rolling to the Remaining Four
Rollout is sequential. Not simultaneous.
Each location gets its own sub-account built from the proven pilot architecture. Same pipeline stages. Same workflow logic. Localized customization: staff access, branding, timezone config, location-specific tags.
The pilot is the template. Every location after is a localized copy — not a new build.
Staff training happens per location, not in a group session. Each team sees their own system, their own pipeline, their own intake flow.
When You’re Ready to Roll
| Check | Done When |
|---|---|
| All intake paths tested | Live leads routing correctly for 7+ days |
| Automations validated | No false triggers, correct timing in local timezone |
| Templates confirmed | Dynamic fields pulling location data, not hardcoded |
| Staff trained and using the system | No workarounds, no “I’ll just do it manually” |
| Edge cases documented | Fix applied and tested, not just noted |
When all five checks are green, you have a proven system. That’s what rolls to the next location.
Frequently Asked Questions
Running on a stack that grew by accident?
Tools added one at a time, never architected together. That's the problem I solve. Book 45 minutes and I'll map what moves, what stays, and what makes sense for your operation.
Book a Discovery Call