By Siddharth GangalA Lavender migration begins with an uncomfortable fact: the public Lavender pages reviewed for this guide do not establish a complete tenant bulk export for every user, email example, score, suggestion, rule, analytic, and relationship. Treat export completeness as an evidence request, not an assumed button.
This page owns Lavender-specific data exit. Use Lavender alternatives to select a replacement, the cold-email platform checklist for mailboxes/domains/senders, and the automation migration checklist for broader orchestration.
Start with the Lavender export evidence gap
Document what the sources prove and stop there. Lavender’s Coach page describes drafts, recipient context, email and template scores, improvement suggestions, team coaching insights, and integrations. Its privacy policy describes personal information, third-party/email data, Google Workspace data treatment, processing, service providers, and a privacy contact. The privacy summary discusses security at a high level.
Those sources help define likely data classes; they do not document a universal bulk export, every available field, stable IDs, relationship semantics, historic score versions, admin analytics extraction, or a guaranteed support service. Absence in public documentation is not proof that Lavender cannot provide something through the tenant, contract, API, or support. Ask, test, and record the answer.
Do not confuse three jobs: access describes information a person or customer may receive under an applicable policy or law; portability describes usable data that can move to another system; deletion concerns disposal. A deletion response can arrive without an importable artifact, while an export can omit configuration and derived history.
Inventory every user, artifact, and relationship
Build one manifest row per object or relationship. Inventory tenant/workspace, teams, users, roles, admins, status and invitations; connected Gmail/Google Workspace, Outlook/Microsoft, Outreach, Salesloft, HubSpot, Apollo, Groove, Gong and other observed integrations; OAuth grants, scopes, mailboxes and sender identities; contacts/recipients and account/research context; email examples, drafts, templates and approved examples.
Include email scores and component scores, score timestamp/version where available, coaching suggestions, edits, accepts/rejects, personalization outputs, recipient research, custom rules or guidance, team benchmarks, manager annotations, admin dashboards, reports, adoption and usage analytics, training progress, billing/seat history, support records, consent/legal basis where applicable, retention settings, deletion requests and audit/security evidence.
For every item capture source ID, human-readable key, parent/team/user/mailbox/contact IDs, timestamps, creator/owner, status, version, source, field schema, classification, retention, export method, format, target ID, checksum, relationship edges, transformation, validation result, rollback need and final disposition. Apply the stable-key discipline from the CRM data migration checklist. Never put credential values in the manifest; reference the vault record and revocation owner.
Build the portability matrix
Use four portability labels.
| Label | Meaning | Required evidence |
|---|---|---|
| Documented export | Current official documentation or tenant UI defines an export | URL/screenshot, role, scope, schema, format, limits, test file |
| Support/contract-dependent | Support or agreement may provide it, but public docs opened here do not establish it | Written scope, delivery method/date, fields, history, relationships, fees |
| Reconstruct | Rebuild from an approved upstream source or retained business artifact | Source authority, transformation, version, reviewer and acceptance test |
| Unavailable/retire | No approved extraction or reliable reconstruction | Owner accepts loss, retention/legal review, replacement behavior |
Start all Lavender operational artifacts as support/contract-dependent until direct evidence supports another label. A mailbox copy of sent email may reconstruct message text and metadata, but not necessarily Lavender’s historic score, suggestion, model/version, user interaction, or manager annotation. A screenshot is reference evidence, not structured portability.
Request a manifest before cancellation
Send an artifact-level request while the contract and tenant remain active. Ask Lavender to state available admin/user export paths, eligible requester and role, tenant scope, file/API format, stable IDs, parent/child relations, timestamps/time zone, deleted/deactivated user handling, score and recommendation history, custom rule/configuration coverage, analytics grain, attachments, limits, pagination, delivery encryption, expiry, cost, SLA, retention, backups, subprocessors and deletion procedure.
Request a data dictionary and sample first. Ask whether exports are full or incremental, whether repeated requests are deterministic, which derived fields are omitted, and whether integrations hold data that is not returned. Record “not available” rather than leaving a blank. Have privacy/legal owners determine applicable rights and contractual obligations; this is not legal advice.
Freeze a snapshot and final delta
Freeze the first snapshot and capture a final delta. Record extraction time, tenant, requester, method, filters, row/file counts, byte size, schema version, timezone, checksums and secure storage location. Preserve the manifest alongside original files; do not normalize away source evidence.
Before cutover, announce a freeze for configuration, team changes, custom guidance, integration changes and training assets. Capture items created or changed since the snapshot, including invitations, deactivations, new examples, score history, analytics periods, deletion requests and support corrections. If Lavender cannot provide an incremental export, agree how to compare two full deliveries or reconstruct the delta from authoritative upstream systems.
FTC guidance on protecting personal information recommends knowing what data exists, limiting retention/access, securing information, and disposing of it when no longer needed. Apply those principles to export files; a migration archive should not become an uncontrolled new copy.
Validate counts, fields, history, and relationships
Validate completeness at four levels. Count reconciliation compares expected and delivered teams, users, mailboxes, integrations, examples, templates, scores, suggestions, analytics periods, rules and requests. Field reconciliation checks populated, null, enum, timestamp, Unicode and long-text behavior. History reconciliation checks earliest/latest dates, versions, edits, deactivations and deletion markers. Relationship reconciliation proves each child resolves to the expected workspace, team, user, mailbox, contact, email/example and analytic period.
Compare both directions: every manifest item should map to one delivery or approved disposition, and every delivered row/file should map to one manifest item. Sample ordinary and edge records, plus every missing, duplicate, orphaned, truncated, misencoded, wrong-owner and unknown item. Preserve counts by status rather than reporting only one completion percentage.
Do not import Lavender scores as universal truth into a new platform. Preserve them as sourced historical fields only if allowed, with timestamp and provenance. A target’s different scoring model should be baselined separately through the email coaching tools evaluation.
Stage the target and prove rollback
Load a representative, non-production target before disconnecting Lavender. Include active/inactive users, teams, multiple mailboxes, examples/templates, scores or reference history if contractually permitted, custom guidance, Unicode, long messages, missing fields, deleted owner, duplicate contact, and analytics boundaries. Verify permissions, relationships, search, display, attribution, correction, retention and deletion.
Keep the source authoritative while staging. Define cutover scope, success gates, incident owner, kill switch and rollback window. Rollback restores integrations and user access only under approved authority, identifies target-created artifacts, prevents duplicate coaching/configuration, and corrects mappings. Preserve source access until the final delta and business/legal acceptance pass; cancellation before evidence is a self-created outage.
Revoke access and collect deletion evidence
Revoke in a controlled order after rollback expires. Disable users and invitations; disconnect mailboxes and integrations in the tenant and upstream provider; revoke OAuth grants/tokens; remove extensions/apps; rotate any shared secrets; remove SSO/SCIM assignments; close support/API access; confirm billing; and update application inventory, data-flow diagrams and incident contacts.
Submit the approved deletion request and ask what tenant, user, email/third-party, derived, log, backup and subprocessor data it covers; exceptions and retention basis; expected timing; and evidence returned. Validate late callbacks and reauthorization cannot restore access. Do not state that deletion equals portability, and do not state every copy vanished unless the evidence supports that exact scope.
Apply the worked example and calculate TCO
Synthetic example—not a Lavender export result: the approved manifest contains 40 users, 12 mailboxes, 8 integrations, 600 email examples/templates, 4,000 score records, 3,200 suggestions, 24 analytics periods and 16 custom rules: 7,900 artifacts. A delivery and reconstruction plan accounts for 7,840, leaves 40 reference-only and 20 unresolved. Accounted rate is 7,880/7,900 = 99.7%, but unresolved suppression or ownership evidence remains a hard gate.
There are 8,600 expected relationship edges and 8,570 accepted. Relationship reconciliation is 8,570/8,600 = 99.7%; list the 30 missing edges by type and disposition. Do not round that into “complete.” Proceed only when hard-gate relationships have no unresolved failures and owners accept bounded historic loss.
TCO = Lavender/support export fees + internal inventory and review + secure storage + reconstruction + target import/mapping + overlap licenses + privacy/security/legal + validation + training + incident/rollback reserve + revocation/deletion and exit − costs demonstrably retired. Model delayed export, incomplete history, manual reconstruction and extended overlap; do not assume universal portability or a free support package.
Print the Lavender migration checklist
☐ Inventory workspace, teams, users, roles, mailboxes and integrations
☐ Inventory contacts, examples, templates, scores, suggestions, research and analytics
☐ Capture rules, training, retention, deletion, audit and relationship IDs
☐ Label documented, support-dependent, reconstructable or unavailable
☐ Request schema, stable IDs, relations, history, limits, delivery and cost
☐ Freeze snapshot, hashes, secure storage and final delta
☐ Reconcile counts, fields, history and edges in both directions
☐ Stage representative target data and prove rollback
☐ Revoke tenant/upstream access and collect scoped deletion/subprocessor evidence
☐ Record gaps, owner acceptance, full TCO and retained evidence
The migration is defensible when every known artifact has an evidence-backed disposition, every critical relationship reconciles, the target is reversible, and the old access paths are revoked—without pretending that privacy deletion language supplied a complete export.