Software Migration Checklist: A 30-Day Switch Plan

The worst day of a software switch is rarely cutover day. It is usually day 34, when someone opens a two-year-old thread in the new system, clicks the attachment, and gets nothing. The export was taken. The export was checked. The export contained links to files, and the account those links pointed at closed four days ago.

Nobody skipped a step there. The steps ran in the wrong order — the irreversible one happened before the check that would have caught it. Everything in a switch stays recoverable right up until one specific act makes it permanent, and most 30-day plans put those permanent acts in the middle, because they are sorted by importance instead of by how much it costs to undo them.

So this runbook is sorted the other way. The cheap-to-redo work goes first, the expensive-to-redo work goes in the middle, and the acts you cannot take back go last, after there is evidence that they are safe.

Sort every step by what it costs to undo, not by how big it is

Before any dates, put each task in one of three buckets.

Free to redo. Running an export again. Importing into an empty target. Reading a contract. These cost you time and nothing else, so do them early, badly, and twice.

Expensive to redo. Anything that involves a queue you do not own: a vendor support ticket, a payment-processor handoff, a scheduled export that takes days to build. You can redo them, but the clock resets, and the clock is the thing you are short of.

Cannot be redone. Cancelling. Deleting. Letting a retention window expire. Letting staff enter real work into the new system, which is the point at which "wipe it and import again" stops being an option and nobody notices it happening.

The whole runbook is just that ordering with dates attached.

Day 0: find the date you are actually working to

Not the renewal date. The last date on which you are still allowed to act on the renewal, which is usually earlier and is usually written somewhere you have not read.

Microsoft's own documentation on what happens when a subscription ends puts the warning plainly: "For some subscriptions, you can only cancel during a limited window of time after you buy or renew your subscription. If the cancellation window has passed, turn off recurring billing to cancel the subscription at the end of its term." (Microsoft Learn, checked 16 August 2026) Annual agreements signed on paper are worse: a non-renewal notice requirement of 30 or 60 days before term end is common, which means the deadline can sit a full two months before the date on your calendar reminder.

Write down three dates: term end, last day to give notice, and last day the data stays reachable after the account closes. Then count backwards from the middle one.

And if the notice date is less than 30 days away, stop. Let it renew, take the extra term, and run this properly. A rushed switch that costs you a month of double subscription is cheaper than one that strands your attachments.

Where the deadline is written varies; the vocabulary does not. Look for a clause headed Term, Renewal or Termination and for the words written notice followed by a number, then work out whether that number counts back from the term end or from a notice date sitting earlier than it. Some jurisdictions put a statutory backstop underneath the question: New York's General Obligations Law § 5-903 makes an automatic renewal clause in a contract for service, maintenance or repair unenforceable against the customer unless the provider gave notice of the renewal "at least fifteen days and not more than thirty days previous to the time specified for serving such notice", and it does not apply where the renewal period is one month or less (New York State Senate, checked 18 August 2026). That is something to put to a solicitor after the date has gone rather than a plan to lean on, but it is a reason to keep the renewal notice you were sent — or to write down that you were not sent one.

Days 1–5: start the exports that have queues in front of them

Some exports are a download. Some are a job in someone else's system, and those have to be started on day 1 whether or not you feel ready.

Google's Data Export tool is the clearest example of the second kind. Google's admin documentation states the export "is available no earlier than 48 hours after you start the export", that it typically takes 72 hours but can take up to 14 days depending on size, that the archive is automatically deleted 60 days from the beginning of the export, and that once started the process cannot be cancelled from the Admin console. It also requires a super admin with 2-Step Verification on and an account at least 30 days old, and organisations over 1,000 users have to contact support first. (Google Workspace admin help, checked 16 August 2026)

Read those numbers together and the scheduling writes itself. Up to 14 days to build, deleted at day 60 from the start, so an export begun on day 1 could finish on day 15 and vanish on day 61. Download it to your own storage the week it appears. Do not leave it sitting in Google's bucket as your archive.

The other trap in this window is exports that look complete and are not. A standard Slack export arrives as JSON containing messages and file links rather than the files, and on the Free plan those file links only cover the last 90 days. Free and Pro export public channels only; private channels and DMs are not a setting you can switch on but an application you have to make, and only Business+ and Enterprise Grid owners can make it. (Slack help centre, checked 16 August 2026) Check which tier you are on before you promise anyone a full archive. If an application is involved it is a queue with a human at the end of it, so it belongs on day 1 with the rest.

Verification rule for this whole block: open the export file, not the app. Pick your oldest record and your most attachment-heavy record and read them out of the file.

Days 3–10: the payment rail, because it is not yours to schedule

If you take card payments and you are changing processor, this starts before almost everything else, and it is the one item that can push a 30-day plan to 60.

Stripe's data-migration documentation describes the shape of it: sensitive card data moves through a formal migration request, encrypted with Stripe's PGP key rather than emailed, and "many processors require the account owner to request a data transfer" from their side as well as yours. Stripe then says the previous processor "might take a few days or several weeks to transfer the final data", and that Stripe "typically imports data within 10 business days of receiving the correct data". (Stripe docs, checked 16 August 2026)

Two consequences that people find out about afterwards. First, any card a customer updates at the old processor between the handoff and the completed import is lost, so you need a plan for updates during the window rather than a hope. Second, the imported records come back with new identifiers and Stripe supplies a mapping file of old ID to new ID that you have to apply to your own database. Your billing history's foreign keys do not migrate themselves.

And the closing line of that process is the one to put on a sticky note: after you leave, confirm the old processor actually cancelled all automatic billing. Two live subscription engines against one customer list is a bad week.

Days 10–20: import once as a test, throw it away, import again

The first import is a diagnostic, not a migration. Load it into an empty target, then sit with the result and count things by hand: comments on a task, line items on an invoice, custom field values, who is recorded as the author, what happened to dates in a different timezone.

Write each gap down with three things beside it: the field or record type that lost data, roughly how many records it touches, and whether the fix is retyping or a script. That third column decides what you can actually finish before cutover. Then wipe the target and import again, cleanly, from a fresh export.

This is the last block where wiping is free. What closes the window is a person rather than a system: someone starts doing real work in the new tool, and from that moment wiping the target destroys work that exists nowhere else, so every subsequent fix becomes a manual patch. Say out loud when that line is crossed and put a date on it, because otherwise it gets crossed by someone being helpful on a Tuesday.

Two classes of gap produce no error message at all, so build the count around those first. Dates are one. HubSpot's import troubleshooting page describes a file carrying "a date value that does not match the format you selected during the import process" as importing the record anyway and leaving the date property empty — a blank cell, not a rejected row. Identity matching is the other: HubSpot matches contacts on email and companies on company domain name, and warns that where Record ID is used as the unique identifier "it'll supersede any other unique identifiers included in the import" (HubSpot knowledge base, checked 18 August 2026). Different importer, same two questions: which column decided that two rows were one record, and which fields arrived empty rather than wrong.

Day 21: cutover is a freeze, not a move

Cutover is not the day the data moves. The data moved last week. Cutover is the day you stop writing to the old system.

Freeze the old system in the evening, take a final delta export of everything created since the main export, load the delta, and open the new system in the morning. Nobody writes to the old tool after the freeze. Not "mostly nobody". The old system's job from this point is to be read. How long it keeps that job is a separate question, answered by an event rather than a number of days.

Announce two things to the team and to anyone outside who touches your systems: the date, and where to go when something is missing. That second one matters more than the first, because the failures in the next block are ones your staff will find before you do.

Days 21–30: the quiet failures, which never send an email

The migration succeeded and the connections did not. This is the block where nothing looks broken.

Automations are the standard casualty. When an app connection breaks, Zapier holds the affected Zap runs rather than dropping them, and clearing them is two steps: reconnect the account, then replay. Zapier's documentation is explicit that Autoreplay "will not replay Zap runs with an on hold status", so held runs sit there waiting for a human, and there is a limit on how long they wait: "You must replay steps within 60 days of the initial trigger event." Manual replay is also a paid feature, which is worth knowing before you find out on day 55. (Zapier help, checked 16 August 2026) Sixty days sounds generous until you notice nobody has opened the Zap history page since cutover.

Go through the rest by hand in the same week. Accounting sync, and specifically whether it created a second copy of your customer list. Anything that fires on a schedule rather than on an event, because a monthly job will not reveal itself as broken for another three weeks. Webhooks pointing at record IDs that no longer exist. Reports and saved filters, which are quietly the most-used feature in most small companies and the least likely to be in any migration scope.

The one-way doors, and the order they have to be in

Only now. And in this sequence.

1. Turn off recurring billing rather than cancelling, if the vendor offers the distinction. It ends the subscription at term end and leaves the account intact until then.
2. Downgrade before you cancel, if a lower tier keeps the data readable. A cheap tier that keeps history reachable is often better value than an archive you have to reconstruct.
3. Cancel. Never delete. Microsoft's documentation says that if you cancel within the cancellation policy window the subscription "moves directly to the Disabled status", where admins can still access and back up data; anything left behind "might be deleted after 90 days and will be deleted no later than 180 days after cancellation". Explicitly deleting a subscription skips that grace entirely — it "skips the Expired and Disabled statuses and SharePoint Online data and content, including OneDrive, is immediately deleted" (Microsoft Learn, checked 16 August 2026). Two buttons, one word apart, and up to 180 days of difference. Note the condition on the first one: outside the cancellation window, cancelling is not the button you get anyway — turning off recurring billing is, which is why it sits at step 1 of this list.
4. Only then remove the admin's access, which is usually the last thing that can retrieve anything.

Nothing in that list happens on cutover day. Cutover day is when you most want the old system back.

The two habits that are not steps

Neither of these has a date on it, which is why they fall out of most plans.

Treat the first week as export week and do not open the new tool at all during it. The pull towards configuring the shiny thing is strong, and the exports are the only part of the plan sitting behind somebody else's queue.

Keep a plain text file called not-migrated.txt from day 0, and write to it the moment anything is found missing — during the test import, during cutover week, whenever a colleague asks where something went. The alternative is trusting that it will be remembered at cleanup, and it will not be. That list runs longer than anyone expects, and it is the honest deliverable of a switch: the imported database says what moved, and only the file says what did not.

Put a date beside each entry, because that file has a second audience beyond the cleanup meeting. The IRS guidance on how long to keep records sets the ordinary period of limitations at three years, holds employment tax records to at least four years after the tax becomes due or is paid, stretches to six years where unreported income exceeds 25 percent of the gross income shown on the return, and runs indefinitely where no return was filed (IRS, checked 18 August 2026). Anything on the list that turns out to be a record in that sense is not a migration annoyance. It is a hole somebody has to account for years later, and this file is where the accounting starts.

Every date above hangs off a single number, and it is the one item on this page that cannot be started late: the last day you are still allowed to give notice. It lives on the billing page or in the signed agreement, rarely on the calendar reminder anyone actually set. Go and find it before you spend another evening comparing the tool you are moving to.

---

Verified against Microsoft, Google, Slack, Stripe and Zapier documentation on 16 August 2026, at the pages linked above, with the New York statute, the HubSpot import page and the IRS retention guidance read and dated 18 August 2026. The date is the shelf life of this page. Vendor tiers, admin interfaces and retention windows move without announcement, and the plan tier named in each source is part of the claim — a 90-day limit quoted from a Free plan page says nothing about a Business+ workspace, so check your own tier against the source rather than against the summary here. Where a vendor now says something different, the contact form reaches me, and the correction goes up with a new verification date rather than as a silent edit. Why every page here is built and dated that way is set out on the about page.