Migration and software
A careful migration checklist for a HoneyBook-based studio
Editorial team · Reviewed
If your studio uses HoneyBook, begin a software move with an inventory of the work that must survive. The checklist is about validating your own records and destination, not assuming every product exports the same things.
A practical sequence
- List active clients, open invoices, accepted agreements, files and scheduled actions.
- Check the current export options in your account and retain original signed records.
- Map a sample export to the destination with a preview and duplicate review.
- Rehearse one client's next real action before redirecting new inquiries.
Work through an example
A studio can move basic contact details while keeping historic agreement PDFs as preserved originals. Its automated sequence may need to be rebuilt and tested separately. Those are different migration outcomes and should be described separately to the team.
Where judgement matters
Do not cancel the old account based on a successful contact count alone. Verify balances, client access and upcoming commitments. Provider plans and export options change; use the official help for the account you actually have.
Make it usable
Open the working tool and work through the decision with your own inputs. Adapt the structured template to preserve the choices and responsibilities. Keep an original copy so later changes remain understandable.
Work the decision
A practice case
An original fictional scenario. Numbers are illustrative inputs; this is not a customer result or a provider performance claim.
Treat a HoneyBook move as a record-preservation project. First inspect the export formats actually available in the customer’s account; do not promise that an arbitrary export contains messages, accepted documents or payment history. Use the records you can obtain and identify the rest as a separate preservation task.
| Decision | Why it matters |
|---|---|
| Inventory live obligations before moving contacts. | Unpaid balances, signed agreements and future bookings are more consequential than a neat address list. |
| Rehearse the actual exported file. | A generic CSV example is not evidence that every provider-specific field maps correctly. |
| Keep historical artifacts read-only when appropriate. | Imported history should not trigger fresh emails, signatures or payment requests. |
Make one usable artifact
Build a migration checklist listing source record, available export, destination mapping, verification result and any retained archive. Include one active project and one completed project.
Then test the difficult case
A signed agreement is available only as a PDF. Preserve the immutable artifact and provenance rather than reconstructing it as a newly accepted document.
Use the linked tool or structured template below to record the result. Confirm it against the actual people, agreements and permissions before using it for an event.