# An agency playbook for migrating client websites to AI builders

Source: https://lindo.ai/guides/agency-website-migration-playbook
Reviewed: 2026-09-03
Prepared by: Lindo Team

An editable project worksheet, not a guarantee of compatibility or rankings.

## Project brief

- Client / site:
- Source platform and account owner:
- Destination and account owner:
- Reason for moving:
- Critical visitor action:
- Content owner:
- Technical / DNS owner:
- Billing owner (separate approval):
- Planned cutover and content freeze:
- Rollback owner and trigger:
- Archive location (keep private):

## Scope

Group clients by migration risk, prove one representative pilot, and size each wave to your QA and support capacity. Keep website, data, domain, and billing approvals distinct.

Good fit: Agencies moving several client websites from Brizy, Duda, WordPress, Webflow, Elementor, or a mixed platform portfolio.

Pause if: A deadline-driven bulk switch without client authorization, source access, tested replacements, and a viable recovery plan.

## Acceptance checklist

### 1. Create the client ownership and dependency register

- [ ] Complete
- Owner:
- Test / evidence link:
- Result and date:
- Exception / approved change:

### 2. Confirm separate website, data, domain, and billing authority

- [ ] Complete
- Owner:
- Test / evidence link:
- Result and date:
- Exception / approved change:

### 3. Route each site to standard, extended, or hold

- [ ] Complete
- Owner:
- Test / evidence link:
- Result and date:
- Exception / approved change:

### 4. Select a representative pilot and define acceptance tests

- [ ] Complete
- Owner:
- Test / evidence link:
- Result and date:
- Exception / approved change:

### 5. Measure cleanup, QA, review, training, and cutover effort

- [ ] Complete
- Owner:
- Test / evidence link:
- Result and date:
- Exception / approved change:

### 6. Separate migration fixes from optional redesign scope

- [ ] Complete
- Owner:
- Test / evidence link:
- Result and date:
- Exception / approved change:

### 7. Assign a tester and evidence to each launch requirement

- [ ] Complete
- Owner:
- Test / evidence link:
- Result and date:
- Exception / approved change:

### 8. Record rollback triggers and the person authorized to act

- [ ] Complete
- Owner:
- Test / evidence link:
- Result and date:
- Exception / approved change:

### 9. Size waves to QA and support capacity

- [ ] Complete
- Owner:
- Test / evidence link:
- Result and date:
- Exception / approved change:

### 10. Handoff ownership and check shared dependencies before cancellation

- [ ] Complete
- Owner:
- Test / evidence link:
- Result and date:
- Exception / approved change:

## URL map

Examples below are illustrative. Replace with the actual source URLs.

| Source URL | Keep / move / merge / retire | Destination | Expected response | Tester / evidence |
| --- | --- | --- | --- | --- |
| /services/roof-repair | Keep | /services/roof-repair | 200 | |
| /roof-repair.html | Move | /services/roof-repair | 301 then 200 | |
| /summer-offer-2022 | Retire | No relevant replacement | 404 or 410 | |

## Dependency register

| Source feature | Business purpose | Destination / replacement | Owner | Acceptance test | Blocker? |
| --- | --- | --- | --- | --- | --- |
| Contact form | Send enquiries to sales | Confirm service | | Test inbox + CRM delivery | Yes until tested |

## Launch decision

- [ ] Client approved content and intentional removals
- [ ] Business actions passed with evidence
- [ ] URLs, redirects, metadata, and public indexability checked
- [ ] Domain change approved; email records preserved
- [ ] Billing changes separately authorized, if any
- [ ] Backup and rollback path available
- [ ] Production enquiry and analytics verified after cutover
- Approved by / date:
- Open exceptions and owners:
- Next review date:

## Primary sources used in the guide

See the linked platform guides for product-specific documentation.