Offboard a client and hand over their data

This page shows how I end an engagement cleanly: the final invoice settled, the client's data exported in formats any system can read, every domain and account confirmed in their name, my access removed, and the project records archived. Done well, the client leaves with everything they paid for, and the relationship ends in a way that still makes a referral possible.

Why a clean exit is part of the offer

Every business owner comparing agencies should ask what happens to their data if they leave. The answer should be short: your data is yours, always, and here is the format you will get it in. Put that promise in the proposal and the agreement, along with how long you keep copies after the engagement ends.

Lock-in is a weak way to keep a client. A business that stays only because leaving is painful is already looking for the exit. Keep clients with the work instead. A client who leaves with clean, complete data may come back, and may send others your way. A client who had to fight for their own records will tell people about that instead.

If onboarding followed the rule that the client owns every account, most of offboarding is removing yourself. The harder part is data that lives in systems you run, such as form logs, databases, and site files. That is what the export is for.

Before you begin

• The agreement's exit terms: notice period, what is owed, what data is delivered, and how long you keep copies after the end date.
• The setup record and access log from onboarding. Together they list every account, integration, and piece of infrastructure to transfer or remove.
• A password manager that can share an item with someone outside your account.
• A scratch database or blank spreadsheet where you can test that the export re-imports.

Offboard the client

1. Confirm the end date and the final invoice

   Put the end date in writing. Bill any outstanding work, and cancel the recurring invoice so nothing bills after the end. Update your own records the day you learn about it: mark the client as ended with the date and a one-line reason, and take their rate out of your revenue numbers. The relationship ends in your records first and winds down technically second.

2. Agree what gets switched off, and when

   Conversion uploads to ad platforms, CRM webhooks, form routing, and scheduled reports keep running until the client says when to stop them. Never cut a live integration on your own. A contact form that stops delivering leads the day a contract ends hurts the business, and your name with it.

3. Export the data in open formats

   CSV for tables, JSON where records have nested fields, and original files for everything else: site files, form submission logs, reports, and creative. Offer the export even if the client does not ask. The next section covers what belongs in it.

4. Write the README and data dictionary

   A plain-language explanation of what is in the archive and how to use it, plus a column-by-column description of every table. Without these, a folder of CSV files is a puzzle.

5. Transfer or confirm ownership

   The domain is registered to the business, in its own registrar account, renewing on its own card. The site moves to the client's host, or the hosting account passes to them. The client is an admin on every ad account and pays for it. The client holds the owner or administrator role in Analytics, Tag Manager, Search Console, and the Business Profile. If the client declines a transfer, for example asking you to keep hosting for a few months, write down that they declined and what happens next.

6. Hand over credentials securely

   Some things transfer as a login rather than a role, such as a hosting control panel or an API key for a service in the client's name. Share those as password manager items, never by email, and ask the client to change each one after the handover. Send any archive password through a different channel than the archive.

7. Remove your access everywhere

   Work down the access log row by row: user seats, the Google Ads manager link, Meta partner access, API keys and tokens you created, deploy keys, and your email address on notifications and alerts. Hand off anything running on your own infrastructure, such as the site, uptime monitors, automations, and tracking endpoints, and take down only what the client confirms they do not want. Mark each row removed, with the date.

8. Archive the project records

   Move the client's folder and code repositories to your archive, read-only, with a one-page offboarding note: end date, reason, what was delivered, what was transferred, and anything the client declined. Your own project records stay. The client's data in your live systems follows the retention terms in the agreement.

9. Ask for feedback, and a referral if it ended well

   Ask what worked, what did not, and what would have changed the outcome. If it ended for a good reason, such as the client bringing the work in-house, ask whether they know anyone who needs the same work and whether they would leave a review. Then write one paragraph for yourself: why they left, what the engagement earned against what it cost, and whether pricing, onboarding, or delivery should change.

What goes in the export

An export is only useful if someone who has never seen your systems can open it and understand it. Package it as one dated archive:

example-business-data-export-2026-09-13.zip
  README.md               what this is and how to use it
  data-dictionary.json    every column: name, type, meaning
  schema.sql              table definitions, for database exports
  profiles.csv            one row per person
  profiles.json
  form_submissions.csv    every lead, with its source fields
  events.csv              every tracked event
  touchpoints.csv         each person's journey, in order
  site-files/             the website as deployed
  reports/                every report delivered

The README answers six questions:

1. What the archive contains, and the date range it covers.
2. How to import it. For a database export: run the schema file, then load each CSV in order.
3. What each table and column means, or where the data dictionary explains it.
4. How the tables relate, such as which ID joins a form submission to a person.
5. How to answer the most common question, such as leads by source per month, with a sample query or spreadsheet recipe.
6. Who to contact for help getting it into a new system.

Verify it works

An export nobody has tested is a promise, not a handover. Before you send it:

1. Check that nothing is missing

   Every table and folder the README lists is in the archive.

2. Match row counts

   Compare each table's row count in the live system with the export. Count rows after importing rather than lines in the file, because a text field containing a line break adds a line without adding a row.

3. Re-import it

   Load the schema and data into a scratch database or a blank spreadsheet, run one real question against it, such as leads by source last month, and compare the answer with the live report.

4. Open the files

   Check that dates, special characters, and commas inside text fields came through intact.

createdb export_test
psql export_test -f schema.sql
psql export_test -c "\copy profiles FROM 'profiles.csv' WITH CSV HEADER"
psql export_test -c "SELECT COUNT(*) FROM profiles"

After the handover, confirm two more things: the client has acknowledged receipt in writing, and every row of the access log shows your access removed.

Keep each client's data isolated so the export is clean

Offboarding is easy when each client's data already lives on its own. If every client's records share one table, the export is a filter you must get exactly right under a deadline, and one mistake hands a client someone else's customers.

• Separate from the start. Give each client its own database, or at least its own schema, before the first form or integration writes to it. Moving a live workflow later takes more steps than starting clean.
• Close the defaults. Databases can ship with wider permissions than you expect. In PostgreSQL, every role may connect to a new database until you revoke the CONNECT privilege from PUBLIC, so granting one client's role access does not keep the others out.
• Test the isolation. After setting permissions, check what each role can actually reach. A grant that succeeds proves the grant, not the restriction.
• Separate reading from writing. If a client gets direct read access, give it its own read-only role, apart from the account your integrations write with.
• Keep secrets out of transcripts. Generate database passwords where they will be used, and never paste one into a command line, a chat, or a document.
• Migrate before you delete. When moving a client's rows out of a shared table, keep the originals until the new location has handled at least one real production write. Deleting the old copy is a separate decision.
• One repository per client site. Handing over a site should mean handing over one repository with its full history, not carving a folder out of everyone's code.

Undo it: when a client comes back

Keep the client's data live for a grace period written into the agreement, such as 30 days. If they return inside that window, re-granting access and switching integrations back on restores the engagement.

After the grace period, delete the client's data from your live systems and confirm the deletion in writing. Be exact about backups in that confirmation: say how long backup copies persist before they age out, so the statement is true. From then on, the export you handed over is the way back, which is one more reason to prove it re-imports before you send it.