Leaving a vendor

Any ERP

How-toIntermediate12 min read

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.

Written for Leaders, finance and operations, administrators.

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.

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 for the clauses and 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

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.
Calculate the date from the contract. Count from the effective or renewal date the contract names, not from the invoice date.
Send it early and in the required form. Keep proof of delivery. If in doubt, send it by every method the contract allows.
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).

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.

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

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.