# Leaving a vendor

> How to exit a vendor cleanly, from planning at signature through notice, data extraction, parallel running, revoking access and data destruction.

Source: https://docs.lumina-erp.com/first-and-third-parties/leaving-a-vendor/

**In short.** Plan the exit when you sign, then start the actual exit about six months before the end date: give notice on time, extract and reconcile every table of your data, run old and new in parallel and revoke every account and integration. Finish with a written certificate that your data was destroyed and a short lessons-learned review.

Leaving a vendor goes well when three things are true: you gave notice on time, you have all of your data in a form you can use and have proved it is complete and nothing still connects to the old vendor after the end date. Each of those is much easier if you planned for it when you signed, so the timeline below runs from the first day of the contract to 30 days after the switch.

The 2023 interagency guidance for banks treats termination as a planned stage of every third-party relationship, and NIST CSF 2.0 (GV.SC-10) asks that supply chain plans cover what happens after an agreement ends. Both are good models for any company.

:::caution[Not legal advice]
Notice requirements, termination fees, data return and data destruction duties depend on your contract and, for personal, health or payment data, on law. Read the contract with counsel before you give notice, and before you tell the vendor you are leaving.
:::

## Plan the exit from day one

The cheapest time to secure an exit is before you sign. After signature, every exit right you lack becomes something to negotiate while the vendor holds your data. The table lists what to secure at signature.

| Secure at signature | Why |
|---|---|
| Data return in a named format (for example CSV or a database backup) within a stated time | You can load it somewhere else without the vendor's help |
| Transition assistance: continued service after notice, at known rates | You are not forced into a same-day cutover |
| Termination for repeated SLA misses and for change of control | You can leave when the service or owner changes |
| A known early termination cost | You can price the decision |
| Deletion within a stated period, with written certification | Your data does not live on after you leave |
| A list of every integration and export in the vendor register | You know what has to be repointed |

See [Contracts, SLAs and data rights](/first-and-third-parties/contracts-slas-and-data-rights/) for the clauses and [Managing vendors after go-live](/first-and-third-parties/managing-vendors-after-go-live/) for the register.

- [ ] **Test the export in the first year.** Request a full export while relations are good, load it into a spreadsheet or database and check that it is complete. Until you have opened an export, you do not know what it contains.
- [ ] **Keep an exit plan summary in the register.** Replacement options, export route, estimated switch time and the notice date.
- [ ] **Document your own configuration.** Settings, rules, templates and custom fields you set up in the vendor's product. Vendors rarely export configuration in a usable form.

## Know why you are leaving

Exit triggers fall into a few groups. The trigger shapes the timeline. A planned replacement can take months, while a vendor failure may give you days.

| Trigger | Typical timeline | Watch for |
|---|---|---|
| Better fit or price elsewhere, at renewal | Planned, 6 to 12 months | Notice windows (do not let the renewal roll while you evaluate) |
| Repeated service failures | Planned or accelerated | Document the failures, which may support termination for cause |
| Vendor acquired, product retired or repriced | Set by the vendor's end-of-life date | Ask for extended support in writing |
| Security incident or loss of trust | Accelerated, weeks | Protect data first, collect evidence, involve counsel |
| Vendor financial failure or shutdown | Emergency, days | Extract data immediately, and use escrow release if you have it |
| Your business changes (sale, merger, new ERP) | Tied to your project | Contract assignment rights |
| Bringing the work in-house | Planned | Staff and knowledge must be ready before the vendor leaves |

## The exit timeline, T-180 to T+30

T is the date the old vendor stops being used for live work. The timeline assumes a planned exit from a tier 1 vendor such as a shipping platform, EDI provider or outsourced service. Shrink it for small vendors. The 180-day start is a rule of thumb that fits a 90-day notice period plus time to prepare.

| When | Workstream | Actions |
|---|---|---|
| T-180 | Decision | Confirm the decision and sponsor, then read the contract for notice period and method, early termination cost, data return and transition terms |
| T-150 | Planning | Name an exit lead; inventory data, integrations, users, reports and documents; pick the replacement or in-house owner |
| T-120 | Notice | Send written notice as the contract requires, even if details are still being discussed, and confirm receipt |
| T-120 | Data | Request a trial full export and map every field to the new system |
| T-90 | Knowledge | Capture configuration, rules and procedures from the vendor and your own users |
| T-90 | Integrations | List every integration, file feed, API key, webhook and scheduled job, then plan each repoint |
| T-60 | Data | Rehearse the migration, reconcile counts and totals, fix mapping |
| T-45 | Communications | Tell customers, suppliers or carriers who see the change, and update instructions and portals |
| T-30 | Parallel | Start parallel running where feasible and compare outputs daily |
| T-14 | Readiness | Go or no-go on the switch against written criteria |
| T-7 | Data | Final extract plan, freeze changes in the old system |
| T | Cutover | Final extract, reconcile, switch integrations, go live on the new service |
| T+1 to T+7 | Revocation | Revoke vendor access to your systems and your users' access to theirs, then rotate shared secrets |
| T+14 | Finance | Reconcile final invoices, credits and prepaid amounts, then stop recurring payments |
| T+30 | Close | Receive the data destruction certificate, archive the final export and hold the lessons-learned review |

Transition assistance in the contract can move T later than the contractual end date. If the contract gives you, say, 90 days of continued service after termination, use them for parallel running.

## Step 1: give notice correctly

1. **Find the notice clause.** Note the period, the method (letter, email to a named address, portal) and the recipient. Some contracts require notice before a renewal date even when you intend to leave at the end of the term.

2. **Calculate the date from the contract.** Count from the effective or renewal date the contract names, not from the invoice date.

3. **Send it early and in the required form.** Keep proof of delivery. If in doubt, send it by every method the contract allows.

4. **Ask for written confirmation.** Include the termination date, the transition assistance you will use and the data return date and format.

## Step 2: extract your data and prove it is complete

Data extraction is where most exits go wrong. The export arrives and looks large. Months later someone finds that attachments, history or a whole table never came across. The table lists what to request and what tends to be forgotten.

| Data to request | Often forgotten |
|---|---|
| Master data (customers, items, addresses, contacts) | Inactive records still needed for history and audits |
| Transactions with full history | Records older than the vendor's default export window |
| Documents and attachments | Files stored separately from the database export |
| Configuration and rules | Rate tables, pricing rules, workflows, templates, custom fields |
| Audit logs | Who changed what, needed for disputes and audits |
| User and permission lists | Needed to rebuild access correctly |
| Reports and saved searches | The logic behind numbers people rely on |

Then verify. The same reconciliation methods used in an ERP cutover apply (see [ERP go-live cutover checklist](/erp-projects/go-live-cutover-checklist/)).

| Check | How | Example (invented) |
|---|---|---|
| Row counts per table | Count records in the export and compare with counts the vendor reports, or with a count visible in their screens | Shipments: 184,220 in export, 184,220 per vendor report |
| Control totals | Sum key amounts by period in both | Freight charges for 2025: $1,412,380 in both |
| Date range | Oldest and newest record per table | Earliest shipment 2019-04-02, matching go-live of the old system |
| Referential integrity | Every transaction points to a customer or item that exists in the export | 0 orphaned shipment lines |
| Sample checks | Open 25 random records in the old system and find each in the export, field by field | 25 of 25 match, including attachments |
| Loadability | Load the export into the new system or a database, beyond opening it | All tables load, 3 date fields needed reformatting |

- [ ] **Get the export in a documented, machine-readable format.** A pile of PDFs cannot be loaded anywhere else.
- [ ] **Reconcile before the vendor's retention period ends.** Once they delete, gaps cannot be fixed.
- [ ] **Keep an archive copy of the final export.** Store it securely, with a record of what it contains and how long you must keep it.
- [ ] **Sign off in writing.** The data owner confirms the reconciliation before you release the vendor from data obligations.

## Step 3: run old and new in parallel

Parallel running means processing the same work in both the old and new service for a period and comparing results. It is the best evidence that the new setup works, and the best protection if it does not. The table compares four approaches.

| Parallel approach | When it fits | Cost |
|---|---|---|
| Full parallel: every transaction in both | Calculations that must match, such as tax, rating or payroll | High staff effort, so keep it short |
| Shadow: new system calculates, old one is used for real | Rating, pricing, tax engines | Low effort, needs a comparison report |
| Pilot: one branch or customer group moves first | Logistics and operational services | Moderate, with phased risk |
| None: hard cutover | Simple, low-risk tools | Lowest effort, highest risk |

Agree the comparison measures and tolerance in advance, for example "tax on 1,000 sample invoices matches to the cent or differences are explained" (invented).

## Step 4: transfer the knowledge

Much of what a vendor did for you lives in people's heads, on both sides.

- [ ] **Document the vendor's recurring tasks.** What they did daily, weekly, monthly and at year end on your behalf.
- [ ] **Capture your users' workarounds.** The spreadsheet that fixes the report, the manual step after the import.
- [ ] **Hold knowledge transfer sessions** under the transition assistance clause, recorded where the contract allows.
- [ ] **Collect runbooks and contact lists** for anything the vendor supported, such as carrier or bank connections.
- [ ] **Confirm who owns each task after T.** Every task on the list has a new owner, internal or at the new vendor.

## Step 5: revoke access and repoint integrations

After T, nothing should connect to the old vendor, and the old vendor should reach nothing of yours. The table lists what to revoke or repoint.

| Item | Action |
|---|---|
| Vendor staff accounts in your systems (ERP, network, remote access tools) | Disable on the day, delete after review |
| Integration and service accounts | Disable and remove from ERP security roles |
| API keys, tokens, SFTP credentials, certificates | Revoke at the vendor and rotate any shared secrets on your side |
| Your users' accounts in the vendor's system | Remove, or confirm the vendor closed the tenant |
| Single sign-on connections | Remove the application from your identity provider |
| Firewall rules and allow lists | Remove the vendor's addresses |
| Scheduled jobs, file drops, webhooks | Repoint to the new service or turn off, then check logs for failures after T |
| Email routing, DNS records, portals | Update records that point to the vendor, such as email sending or subdomains |
| Documentation and user instructions | Replace references to the old vendor |

- [ ] **Search the ERP and integration logs for the vendor's endpoints one week after T.** Forgotten jobs show up as errors.
- [ ] **Review access with the same method as a periodic access review.** See [Security roles and access reviews](/erp-projects/security-roles-and-access-reviews/).

## Step 6: close the finances

- [ ] **Confirm the final invoice matches the contract.** Pro-rated fees, early termination cost if any, transition assistance charges.
- [ ] **Recover prepaid amounts and credits.** Annual fees paid in advance and unused SLA credits.
- [ ] **Stop recurring payments.** Card subscriptions, ACH debits and marketplace billing.
- [ ] **Close the vendor record in accounts payable** once the final invoice is paid, to stop stray payments.

## Step 7: get a certificate of data destruction

Once you have confirmed your export, ask the vendor to delete your data and confirm in writing. For personal data, GDPR Article 28 requires processors to delete or return it at the controller's choice when the service ends, and HIPAA business associate contracts must require return or destruction of health information at termination where feasible (45 CFR 164.504(e)).

A useful certificate covers the elements below. Paraphrase the requests in your own letter.

| Element | What to request |
|---|---|
| Scope | All customer data, including production, test and backup copies, and copies held by subprocessors |
| Method | The sanitization method, with reference to a standard such as NIST SP 800-88 for media sanitization |
| Backups | When remaining backup copies will expire, and that they are protected until then |
| Date | The date deletion was completed |
| Exceptions | Any data retained for legal reasons, what it is and how long |
| Signature | A named, authorized officer of the vendor |

## Step 8: communicate the change

The table lists who needs to hear about the change, and when.

| Audience | What they need | When |
|---|---|---|
| Internal users | What changes for them, training, where to get help | From T-45, again at T |
| Customers | Only if they see the change: new portals, tracking links, invoice formats, payment instructions | T-45 to T-14 |
| Suppliers and carriers | New integration details, contacts, EDI identifiers | T-60 to T-30 |
| The departing vendor | Professional, clear and in writing, since you may need them again | At notice and at close |
| Auditors and insurers | If the vendor was in scope of audits or policies | After T |

:::tip[Leave on good terms]
Markets are small. The account manager you leave today may be at your next vendor, and you may need the old vendor for records or a dispute. Be clear and firm, and keep the tone professional.
:::

## Step 9: hold a lessons-learned review

Within 30 days of T, spend an hour with the exit team on what to change next time, and put the answers into your selection and contract templates.

- What would have made this exit faster or cheaper, if it had been in the contract?
- What data or integration did we find late, and why was it not in the register?
- How long did the exit take compared with the exit plan summary?
- What should we ask the next vendor during selection because of this?

## Red flags during an exit

The table pairs common exit problems with a response.

| Red flag | What to do |
|---|---|
| The vendor goes quiet after notice | Escalate to their leadership in writing, citing the transition clause |
| Export offered only as PDFs or screenshots | Point to the data return clause and involve counsel if needed |
| New "migration services" fees not in the contract | Ask which contract term they rely on |
| Service quality drops sharply after notice | Document it, since it may breach SLAs you can still enforce |
| Pressure to renew "just for three months" at a high rate | Compare with the transition assistance terms you already have |
| No clear answer on backups and subprocessor copies | Do not accept a destruction certificate that leaves them out without saying so |

## Questions to ask the departing vendor

- What exactly will the full export contain, in what format, and how will we know it is complete?
- Which records, attachments or configuration are not included in a standard export?
- How long will our data remain available after the termination date, and in what state?
- Which subprocessors hold copies of our data, and how will those copies be deleted?
- What transition assistance can you provide, at what rate, and who will do it?
- When will you send the certificate of destruction, and who will sign it?

For cloud services from providers serving the European Union, the EU Data Act sets switching rights, including a maximum two-month notice period to start switching and a transition period of up to 30 calendar days in most cases (as read on EUR-Lex, retrieved 2026-09-28). Ask a provider whether it extends similar terms to you.

## Next steps

Pick your most critical vendor and write its exit plan summary today: notice period and date, export format, the integrations that touch it and who would replace it. Then request a test export and reconcile it against a few row counts. If the export is incomplete or the contract is silent on return and deletion, you now know what to fix at the next renewal, while you still have bargaining power.

## Sources

- [Interagency Guidance on Third-Party Relationships: Risk Management (Federal Reserve, FDIC, OCC, June 2023)](https://www.federalregister.gov/documents/2023/06/09/2023-12340/interagency-guidance-on-third-party-relationships-risk-management)
- [The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 (GV.SC-10, activities after an agreement ends)](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf)
- [SP 800-88 Rev. 2, Guidelines for Media Sanitization (NIST, September 2025)](https://csrc.nist.gov/pubs/sp/800/88/r2/final)
- [Regulation (EU) 2016/679 (GDPR), Article 28(3)(g) deletion or return of personal data (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2016/679/oj)
- [45 CFR 164.504(e), return or destruction of protected health information at termination (eCFR)](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.504)
- [Regulation (EU) 2023/2854 (Data Act), Chapter VI on switching between data processing services (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj)

---

Epicor, Prophet 21, P21 and DynaChange are trademarks or registered trademarks of Epicor Software Corporation registered in the United States and other countries. Kinetic is a trademark of Epicor Software Corporation. Lumina ERP is an independent consultancy and is not affiliated with, sponsored by or endorsed by Epicor.