Before you give notice: the checklist

The worst time to learn what your contract says is after you've told the vendor you're leaving. Leverage, goodwill and access all shrink from that moment. So this checklist is ordered by one rule: do everything you can while you are still, as far as the vendor knows, a happy customer.

The contract

• Find the notice period. Sixty days is common; some run to a full renewal cycle. Put the last possible notice date on a calendar with a reminder a month before.
• Read the data-return terms. What format, how long after termination, and whether there is a fee. If there are no terms, assume you get nothing you haven't already exported.
• Check license transfer and termination fees. Some vendors require approval for a transfer and charge for it. Some hosted agreements have been litigated over termination; read yours as if it will be.
• Note the auto-renewal clause. Many contracts renew silently, and a migration that runs a month past the renewal date can cost a year.

The data

• Take a full backup you control, now. Not the vendor's backup. Yours, on your own storage, and confirm it restores. Migrations work from a backup, never the live files.
• Export letter images and call recordings from your print vendor and dialer for your full retention period. They are not in your collection system and they will not migrate.
• Inventory custom reports, scheduled jobs and stored procedures. Sort into: run monthly, run yearly, never opened. Only the first pile needs rebuilding before cutover.
• Don't run year-end cleanup routines during the export window. Some legacy platforms have month-to-date clearing steps that permanently discard data; one is a known trap.

The money

• Tell your payment processor that a re-point of the token vault is coming. It is routine work for them; get the fee and the lead time in writing. This is the step that keeps every consumer's payment plan running without anyone re-entering a card.
• Count your databases. Multi-currency, pre-collect, remote offices and shared instances with clients were often set up as separate systems. Each one needs to be in scope, and shared ones need an agreement on who owns which records before anyone exports.

The people

• Book the specialist. If your current platform needs a particular developer to get data out (some do), reserve them for the export window before you tell anyone else.
• Draft the client letter. A short note that you are moving systems, when, what it means for them (usually nothing), and who to call. Send it after cutover is dated, before it happens.

Then give notice

With the backup taken, the exports done, the processor briefed and the contract read, giving notice becomes a formality rather than a negotiation. That is the whole point. The vendor's leverage was always the things on this list; once they are handled, what's left is a date.

Do everything you can while you are still, as far as the vendor knows, a happy customer.

Each guide at resolvah.com/migrate has a version of this list tuned to the platform you're leaving, including the specific traps and the processors involved.