Vendor Exit
Vendor exit transfers technology services, data, and responsibilities away from a current vendor to either a replacement vendor, an in-house solution, or decommissioning. Execute this procedure when a contract ends, a vendor relationship terminates, or your organisation consolidates services. The outcome is complete separation from the vendor with all data extracted, services transitioned, and contractual obligations fulfilled.
Exit complexity varies by vendor type. A SaaS productivity tool with 50 users and no integrations requires 2-4 weeks. An ERP system processing financial transactions across 12 country offices with 30 integrations requires 6-12 months. This procedure scales to both scenarios through phased execution with decision points at each stage.
Prerequisites
| Requirement | Detail |
|---|---|
| Exit decision | Documented approval from budget holder and IT leadership with rationale |
| Contract review | Legal review of termination clauses, notice periods, and data rights completed |
| Alternative identified | Replacement service selected and ready for migration, or decommission decision confirmed |
| Timeline | Exit date confirmed with minimum 90 days lead time for complex systems, 30 days for simple services |
| Resources | Migration team assigned: project lead (0.5 FTE), technical lead (0.5-1.0 FTE), subject matter experts (variable) |
| Budget | Exit costs estimated and approved: data extraction, parallel running, early termination fees if applicable |
| User communication | Stakeholder notification plan drafted |
Verify contract termination requirements before initiating exit:
Contract review checklist:[ ] Notice period identified (typically 30-90 days)[ ] Written notice requirements (email, registered post, portal)[ ] Data extraction rights confirmed[ ] Data retention period post-termination (typically 30-90 days)[ ] Early termination fees calculated if applicable[ ] Asset return obligations identified[ ] Surviving clauses identified (confidentiality, indemnity)Data extraction deadlines
Most contracts provide limited windows for data extraction after termination. Confirm the exact deadline and complete extraction before contract end. Post-termination access is not guaranteed regardless of contract language.
Procedure
Phase 1: Exit planning
- Create a vendor exit register documenting all touchpoints with the vendor. Include every system, integration, user account, and data store. A representative register for a CRM vendor might contain:
VENDOR EXIT REGISTER ==================== Vendor: ExampleCRM Ltd Contract end: 2025-06-30 Notice given: 2025-03-15 Data extraction deadline: 2025-07-31
SYSTEMS ------- - CRM platform (production): 847 users, 2.3M contact records - CRM platform (sandbox): 12 admin users, test data only - Email integration: bidirectional sync with Microsoft 365 - Website forms: 4 web forms submitting to CRM API - Reporting portal: 23 scheduled reports, 8 dashboards
INTEGRATIONS ------------ - Finance system: opportunity data → invoice creation - Marketing platform: contact sync (bidirectional) - Support desk: contact lookup, case logging - Data warehouse: nightly extract of activity data
DATA STORES ----------- - Contact records: 2.3M records, 4.2 GB - Activity history: 12M records, 8.1 GB - Documents: 340,000 attachments, 89 GB - Email tracking: 2.1M records, 1.8 GB
USER ACCOUNTS ------------- - Standard users: 823 - Admin users: 12 - API service accounts: 4 - Integration accounts: 3- Map dependencies between your vendor and other systems. Create a dependency diagram showing data flows:
+------------------+ +------------------+ +------------------+ | | | | | | | Website Forms +---->+ +---->+ Finance System | | (4 forms) | | | | (invoicing) | +------------------+ | | +------------------+ | | +------------------+ | EXITING | +------------------+ | |<--->+ VENDOR +<--->+ Marketing | | Microsoft 365 | | (CRM) | | Platform | | (email sync) | | | | (contacts) | +------------------+ | | +------------------+ | | +------------------+ | | +------------------+ | +<----+ +---->+ | | Support Desk | | | | Data Warehouse | | (case logging) | +------------------+ | (nightly ETL) | +------------------+ +------------------+- Calculate the exit timeline working backwards from contract end date. Each integration requires testing time after reconnection. Each data store requires extraction, validation, and import time:
EXIT TIMELINE (90-day example) ==============================
Day 0: Exit initiated (contract notice given) | +-- Days 1-14: Planning and preparation | - Complete exit register | - Map dependencies | - Schedule data extraction | - Configure replacement system | +-- Days 15-45: Data extraction and migration | - Extract all data from vendor | - Validate extraction completeness | - Transform data for target system | - Import to replacement system | - Validate import accuracy | +-- Days 46-70: Integration cutover | - Redirect integrations one at a time | - Test each integration before next | - Parallel run period for validation | +-- Days 71-80: User transition | - Train users on replacement system | - Switch user access | - Support hypercare period | +-- Days 81-90: Decommission and close - Revoke all vendor access - Confirm data deletion - Final billing reconciliation - Document lessons learned- Notify the vendor formally according to contract requirements. Written notice prevents disputes about termination date. Retain proof of delivery for contracts requiring registered post or signed acknowledgment.
NOTICE TEMPLATE ===============
To: [Vendor legal name] From: [Your organisation legal name] Date: [Date] Re: Termination of Agreement dated [contract date]
We hereby give notice of termination of the above Agreement in accordance with Clause [X]. The effective termination date is [date, calculated per notice period].
Please confirm: 1. Receipt of this notice 2. Final invoice amount and payment date 3. Data export availability and deadline 4. Asset return instructions if applicable
We request data export in [format] by [date].
[Signature block]Phase 2: Data extraction and validation
Request all available export formats from the vendor. Common formats include CSV, JSON, XML, and proprietary backup files. For the CRM example:
Data type Available formats Selected format Reason Contacts CSV, JSON, XML CSV Universal import compatibility Activities JSON, XML JSON Preserves nested relationships Documents ZIP archive ZIP archive Only option for binary files Reports PDF, Excel PDF For reference, not migration Execute data extraction using vendor-provided tools or APIs. Track extraction progress and verify completeness:
# Example API-based extraction script (pseudocode)
# Export contacts in batches of 10,000 OFFSET=0 BATCH_SIZE=10000 TOTAL=2300000
while [ $OFFSET -lt $TOTAL ]; do curl -H "Authorization: Bearer $API_TOKEN" \ "https://api.vendor.com/v2/contacts?offset=$OFFSET&limit=$BATCH_SIZE" \ -o "contacts_batch_$(printf '%06d' $OFFSET).json"
OFFSET=$((OFFSET + BATCH_SIZE)) echo "Extracted $OFFSET of $TOTAL records" done
# Verify record count jq -s 'map(.data | length) | add' contacts_batch_*.json # Expected output: 2300000- Validate extracted data against source system counts. Run validation queries comparing record counts, checksums, and sample records:
DATA VALIDATION REPORT ====================== Extraction date: 2025-04-15 Source system: ExampleCRM
RECORD COUNTS ------------- Object Source Extracted Variance ------------------------------------------------ Contacts 2,300,412 2,300,412 0 (0.00%) Activities 12,045,891 12,045,891 0 (0.00%) Documents 340,217 340,217 0 (0.00%) Email tracking 2,112,445 2,112,445 0 (0.00%)
SAMPLE VALIDATION ----------------- Randomly selected 100 records per object type. Field-by-field comparison: 100% match
CHECKSUM VERIFICATION --------------------- Contacts SHA-256: a3f2...8b4c (verified) Activities SHA-256: 7e21...9d3a (verified)
VALIDATION STATUS: PASSED- Transform extracted data to match the target system schema. Document all transformations for audit purposes:
# Example transformation: CRM contact to new system format
def transform_contact(source_record): """ Transform vendor CRM contact to target system format. Source fields mapped to target fields with transformations. """ return { # Direct mappings 'id': source_record['contact_id'], 'email': source_record['email_address'].lower().strip(), 'phone': normalize_phone(source_record['phone']),
# Field renaming 'first_name': source_record['given_name'], 'last_name': source_record['family_name'],
# Concatenation 'full_address': concatenate_address( source_record['street'], source_record['city'], source_record['postal_code'], source_record['country'] ),
# Lookup transformation 'status': STATUS_MAPPING.get( source_record['lifecycle_stage'], 'unknown' ),
# Date format conversion 'created_date': parse_date( source_record['created_at'] ).isoformat(),
# Preserve unmapped fields for reference '_source_data': source_record }- Import transformed data to the replacement system. Execute imports in dependency order: reference data first, then primary records, then related records:
IMPORT SEQUENCE ===============
Step 1: Reference data (no dependencies) - Account types - Industry codes - Geographic regions - Custom picklist values
Step 2: Primary records - Organisations/Accounts - Contacts (linked to organisations)
Step 3: Related records - Activities (linked to contacts) - Opportunities (linked to organisations and contacts) - Documents (linked to parent records)
Step 4: Relationship records - Contact-to-organisation relationships - Opportunity team members - Account hierarchiesParallel extraction
Start data extraction as early as possible. You can extract data while still using the vendor system. This creates a safety buffer if extraction encounters problems and allows validation time before the contract ends.
Phase 3: Service transition
- Redirect integrations one at a time, validating each before proceeding to the next. Changing all integrations simultaneously masks which integration caused any problems observed:
INTEGRATION CUTOVER SEQUENCE ============================
Integration 1: Website forms (lowest risk) ------------------------------------------ Day 46: Update form endpoints to new system Day 47: Validate 24 hours of submissions Day 48: Confirm no data loss, proceed to next
Integration 2: Support desk lookup (read-only) ---------------------------------------------- Day 49: Redirect API calls to new system Day 50: Validate lookup responses match expected format Day 51: Confirm agent workflows unaffected
Integration 3: Marketing platform (bidirectional) ------------------------------------------------- Day 52: Pause sync from old vendor Day 53: Configure sync to new system Day 54: Run initial sync Day 55-57: Validate bidirectional sync accuracy
Integration 4: Finance system (critical) ---------------------------------------- Day 58: Test in non-production environment Day 59: Schedule cutover during low-activity period Day 60: Execute cutover with rollback plan ready Day 61-63: Intensive validation of financial data flow
Integration 5: Data warehouse (dependent on others) --------------------------------------------------- Day 64: Update ETL jobs to pull from new system Day 65: Run parallel extraction from both systems Day 66: Compare outputs, resolve discrepancies Day 67: Decommission old vendor ETL jobs- Run a parallel operation period where both old and new systems receive data. Compare outputs to identify discrepancies:
PARALLEL RUN VALIDATION =======================
Period: 2025-05-15 to 2025-05-22 (7 days)
Daily reconciliation: - Contacts created: Old=127, New=127 (match) - Activities logged: Old=4,521, New=4,518 (3 missing, investigated) - Emails tracked: Old=892, New=892 (match)
Discrepancy investigation: - 3 missing activities traced to timezone handling difference - Fix applied to new system transformation - Re-validated: now matching
Parallel run status: PASSED Go/No-go decision: GO for full cutoverTrain users on the replacement system before access cutover. Schedule training sessions by user group with role-specific content:
User group Count Training duration Topics Sales 234 2 hours Contact management, activity logging, reports Marketing 45 3 hours Campaign tracking, contact sync, segmentation Support 89 1.5 hours Contact lookup, case linking, knowledge base Managers 28 1 hour Dashboards, team reports, approval workflows Admins 8 4 hours Configuration, user management, integrations Execute user access cutover. Disable old system access and enable new system access simultaneously to prevent split-brain data entry:
ACCESS CUTOVER PROCEDURE ========================
Timing: Friday 18:00 (lowest activity period) Duration: 2 hours planned, 4 hours maximum
18:00 - Announce system transition via email and Slack 18:05 - Disable new user creation in old system 18:10 - Set old system to read-only mode 18:15 - Run final data sync from old to new 18:30 - Validate sync completion 18:45 - Enable write access in new system 18:50 - Send "go live" notification to all users 19:00 - Begin monitoring for user issues
Rollback trigger: >10 critical issues or data integrity failure Rollback procedure: Re-enable old system write access, disable new system, investigatePhase 4: Access revocation and closure
- Revoke all vendor access in sequence. Start with service accounts and API keys, then integration accounts, then user accounts:
ACCESS REVOCATION SEQUENCE ==========================
1. Service accounts (immediate risk if compromised) [ ] API production key: revoked 2025-06-01 [ ] API staging key: revoked 2025-06-01 [ ] Webhook signing secret: rotated 2025-06-01
2. Integration accounts [ ] Finance integration: disabled 2025-06-05 [ ] Marketing sync: disabled 2025-06-05 [ ] Warehouse ETL: disabled 2025-06-05
3. Admin accounts [ ] IT admin 1: disabled 2025-06-10 [ ] IT admin 2: disabled 2025-06-10 [ ] Super admin: disabled 2025-06-15 (last)
4. Standard user accounts [ ] Bulk disable script: executed 2025-06-10 [ ] Verified 847 accounts disabled- Request written confirmation of data deletion from the vendor. Under GDPR and similar regulations, you have the right to confirmation that data has been deleted:
DATA DELETION REQUEST =====================
To: [Vendor DPO/Legal] From: [Your organisation] Date: [Date]
Following termination of our agreement, we request deletion of all data held on our behalf, including:
- All production data (contacts, activities, documents) - All backup copies - All data in development/staging environments - All data in vendor subprocessor systems
Please confirm in writing: 1. Deletion completion date 2. Categories of data deleted 3. Any data retained and legal basis for retention 4. Deletion method used
Requested response deadline: [30 days from termination]- Reconcile final billing. Review the final invoice against contract terms, usage records, and any credits owed:
FINAL BILLING RECONCILIATION ============================
Contract period: 2022-07-01 to 2025-06-30 Final invoice date: 2025-07-01 Invoice amount: £45,230.00
VERIFICATION ------------ Base subscription (847 users @ £50/user/month): £42,350.00 Overage charges (API calls): £1,890.00 Professional services (unused): £0.00 Credits (service level breach, March 2025): -£500.00 Early termination fee: £0.00 Storage overage: £1,490.00 ------------------------------------------------------- Calculated total: £45,230.00
Invoice matches calculation: YES Payment authorised: YES Payment date: 2025-07-15Recover or return any vendor-owned assets. Physical hardware, software tokens, and documentation must be returned according to contract terms:
Asset type Quantity Location Return method Completed Hardware tokens 12 London office Courier to vendor 2025-06-25 Documentation 3 binders IT storage Shred (confirmed no return required) 2025-06-20 Training materials Digital SharePoint Deleted 2025-06-15 Archive all exit documentation for audit and reference. Retain for minimum 7 years or as required by your records retention policy:
EXIT DOCUMENTATION ARCHIVE ==========================
Location: SharePoint/IT/Vendor-Exits/2025-ExampleCRM/
Contents: - Contract and amendments (PDF) - Termination notice and acknowledgment (PDF) - Data extraction validation reports (PDF) - Transformation documentation (MD) - Parallel run reports (XLSX) - Final billing reconciliation (PDF) - Data deletion confirmation (PDF) - Lessons learned document (DOCX) - Exit project closure report (PDF)
Retention: 7 years (delete 2032-06-30) Access: IT Leadership, Finance, LegalPhase 5: Post-exit verification and closure
- Verify no residual access or data remains with the vendor. Check for orphaned accounts, cached data, and integration remnants:
POST-EXIT VERIFICATION CHECKLIST ================================
Access verification: [ ] All user accounts confirmed disabled [ ] API keys confirmed revoked [ ] SSO/federation removed from IdP [ ] Vendor removed from identity provider [ ] No vendor entries in DNS (CNAME, MX records) [ ] No firewall rules permitting vendor access
Data verification: [ ] Vendor deletion confirmation received [ ] No organisation data in vendor system (tested login) [ ] No cached data in CDN/edge systems [ ] Subprocessor deletion confirmed
Integration verification: [ ] All integrations pointing to replacement system [ ] No error logs showing attempted vendor connections [ ] Webhook endpoints updated or removed
Financial verification: [ ] Final invoice paid [ ] No recurring payments scheduled [ ] Procurement system updated [ ] Budget reallocation completed- Conduct a lessons learned session with the exit project team. Document what worked, what caused problems, and recommendations for future exits:
LESSONS LEARNED: EXAMPLECRM EXIT ================================
Date: 2025-07-15 Participants: [Names]
WHAT WORKED WELL ---------------- - Early data extraction (started 60 days before end) gave buffer for validation issues - Phased integration cutover isolated problems - User training before cutover reduced support load
WHAT CAUSED PROBLEMS -------------------- - Document extraction slower than expected (340K files took 5 days, not 2 days estimated) - Timezone handling differences required transformation fix - One integration owner was on leave during cutover window
RECOMMENDATIONS --------------- 1. Add 100% buffer to document extraction time estimates 2. Include timezone test cases in validation suite 3. Require backup owners for all integration cutovers 4. Schedule exits to avoid holiday periodsUpdate organisational documentation to remove vendor references. Configuration documentation, architecture diagrams, and runbooks require updates:
Document Location Update required Completed System architecture diagram Confluence/IT/Architecture Remove CRM vendor, add replacement 2025-07-10 Integration inventory SharePoint/IT/Integrations Update 5 integration entries 2025-07-12 DR runbook IT wiki Update CRM recovery procedures 2025-07-14 Vendor contact list IT wiki Remove vendor contacts 2025-07-08 Security questionnaire responses Compliance folder Archive vendor responses 2025-07-08 Close the exit project formally with a closure report to stakeholders:
VENDOR EXIT CLOSURE REPORT ==========================
Project: ExampleCRM Exit Duration: 2025-03-15 to 2025-07-15 (122 days) Status: COMPLETE
SUMMARY ------- Successfully transitioned 847 users and 2.3M contact records from ExampleCRM to NewCRM platform. All integrations migrated. No data loss. No unplanned downtime.
METRICS ------- - Data migrated: 2.3M contacts, 12M activities, 340K documents - Users transitioned: 847 - Integrations migrated: 5 - Training sessions delivered: 12 - Support tickets during transition: 127 (resolved within SLA)
BUDGET ------ - Planned: £35,000 - Actual: £38,500 - Variance: £3,500 (10%) over - additional transformation work
TIMELINE -------- - Planned: 90 days - Actual: 92 days (extended for document extraction)
OPEN ITEMS ---------- None. Project complete.
ATTACHMENTS ----------- - Lessons learned document - Final billing reconciliation - Data deletion confirmationVerification
Confirm exit completion through these verification steps:
Access verification: Attempt to log in to the vendor system using previously valid credentials. Login should fail. Check your identity provider for any remaining federation or SSO configuration pointing to the vendor.
# Check DNS for any remaining vendor referencesdig +short CNAME crm.example.org# Expected: No results or points to new system
# Check for vendor entries in firewall rules (example)firewall-cmd --list-rich-rules | grep -i "vendor.com"# Expected: No resultsData verification: Request final data subject access request (DSAR) from the vendor for your organisation. Response should confirm no data held. If data is returned, escalate with vendor legal team.
Financial verification: Check payment systems for any scheduled recurring payments to the vendor. Verify procurement system shows contract as terminated.
Expected state after successful exit:- Vendor login: DENIED- SSO federation: REMOVED- DNS records: UPDATED OR REMOVED- Firewall rules: NO VENDOR REFERENCES- Payment schedules: CANCELLED- Procurement status: TERMINATED- Data deletion: CONFIRMED IN WRITINGTroubleshooting
| Symptom | Cause | Resolution |
|---|---|---|
| Data export fails repeatedly | API rate limiting or timeout | Request higher rate limits from vendor, export during off-peak hours, use batch exports instead of streaming |
| Vendor claims data export is not included | Contract ambiguity about data ownership | Escalate to legal, reference GDPR portability rights (Article 20) if processing personal data under consent or contract |
| Export format incompatible with target system | Vendor uses proprietary format | Request alternative format, build custom transformation, or engage third-party migration tool |
| Cannot extract all historical data | Vendor retains only 2 years of data | Check backup availability, request archive restoration, document data loss for compliance records |
| Integration cutover causes production issues | Dependency not identified in planning | Rollback to old system, extend parallel running, complete dependency mapping before retry |
| Users resist using replacement system | Insufficient training or system capability gaps | Extend hypercare support, additional training, escalate capability gaps to replacement vendor |
| Vendor continues charging after termination | Billing system not updated | Dispute charges in writing, reference termination notice date, escalate to vendor legal |
| Vendor delays data deletion confirmation | Administrative backlog or process not in place | Set deadline in writing, escalate to DPO, file regulatory complaint if GDPR applies and deadline missed |
| Orphaned integrations attempt vendor connections | Integration not fully decommissioned | Check all environments (production, staging, development), update or remove integration configurations |
| Post-exit audit discovers data retained at vendor | Subprocessor retention or backup lag | Demand deletion with evidence, document compliance gap, consider regulatory notification if personal data |
| Contract requires asset return but assets are lost | Physical assets misplaced during organisational change | Document loss, negotiate replacement value, update asset tracking for future exits |
| Final invoice disputes delay closure | Disagreement on charges or credits | Document position with evidence, engage finance and legal, consider mediation for significant amounts |
Regulatory obligations persist
Data protection obligations survive contract termination. If the vendor suffers a breach affecting your data after termination, you remain responsible for notifying affected individuals. Obtain data deletion confirmation in writing and retain as compliance evidence.