How long should you run two systems in parallel?

Long enough for one full turn of the slowest thing you do, plus the corrections that arrive after it. For most small companies that is one month-end close performed entirely in the new system and the fortnight of fixes that follows, which puts a cutover on the 3rd at roughly six weeks rather than 30 days. Typing into both systems is a different question and should stop within days.

Is downgrading the old system safer than cancelling it?

Only if the cheaper tier still shows you the history. Slack states that on the free version you are limited to the most recent 90 days of message and file history and that data more than one year old will be deleted, so downgrading a chat tool destroys the thing you were keeping. Intuit, by contrast, says a cancelled QuickBooks Online subscription keeps read-only access for one year. Cancelling is sometimes the gentler of the two, so read the tier page before assuming.

Should staff enter new records into both systems after cutover?

No, apart from a narrow class you name in writing and cap with a date. Two systems holding the same records disagree within days, nothing announces the disagreement, and the person reconciling it is the same person still learning the new tool. Pick one system as the place work is written and let the other one only be read.

How do I know nobody still needs the old system?

Ask the old system. Most vendors expose a last-active or login report to admins, and two weeks with no logins is a stronger signal than asking the team, who will say yes to be safe. If your vendor does not expose that report, that absence is itself worth writing down before the account closes.

Parallel Running: How Long to Keep Both Systems

Take a switch twelve days past cutover. The customer list reads 1,247 records in the new system and 1,231 in the old one. The figures are picked to stand in for yours. Both are defensible. Sixteen records exist on one side and not the other, and nobody can say which sixteen are the current ones, because for twelve days people have been typing into whichever screen was already open.

That is what a parallel run actually costs. Not the second subscription. The second subscription is usually the cheapest line in the entire switch, and paying it for an extra six weeks is the easiest insurance anyone will ever buy. The cost is that two live systems holding the same records will disagree inside a week, no error message will mention it, and the reconciliation lands on the person who is already the busiest one in the building.

Two different things get called running in parallel

They have opposite cost curves, so keeping one word for both is how the decision gets made badly.

Dual entry. Both systems are live. Staff create and edit records in both, either by policy or by habit. Every extra day of this produces more divergence and more reconciliation, so the correct length is the shortest one you can survive, measured in days.

Read-only fallback. The old system is still open, still paid for, and nobody writes to it. It exists to answer questions: what did that job actually cost, what did we tell this customer in March, what was the setting on that report. Every extra week of this costs one subscription and nothing else, so the correct length is generous, measured in weeks.

The line between them is the freeze. The 30-day switch runbook puts it on cutover evening, where the old system stops being somewhere you write and becomes somewhere you read. When people ask how long to run in parallel, they are almost always asking about the second thing while the risk sits in the first.

Divergence starts on day two and nothing announces it

Three things drift, in roughly this order.

Master records go first. A phone number gets corrected in the old system because that is where the invoice was already open. A new customer is created in the new system under a slightly different company name. Neither edit is wrong and neither system flags it.

Numbering sequences go second, and they are worse, because both systems will happily issue INV-1042. Document numbers are the one field customers and accountants quote back at you, so a collision is still being untangled months later.

Statuses go last and are hardest to spot. A job is marked complete in one system and left open in the other, and the report that finally reveals it is the monthly one, which by definition arrives after the damage.

Then the sync layer arrives to make all of it permanent. If both systems are connected to the same accounting file, both will create customers in it, which is one of the standard routes to duplicate customers and payouts that will not reconcile. Cleaning up a duplicate that has already carried transactions is not the same job as cleaning up one that has not.

The arithmetic is unkind even at small volumes. Half an hour a day of comparing two lists, across three weeks and two people, is more than ten hours of work that produces nothing new, and it is spent by exactly the staff whose confidence in the new system you were trying to build.

What extends a parallel run is never a decision. It is the sentence about keeping it another month just in case, which sounds free because the subscription is small. It is not free. A fallback that people are allowed to use casually stops being a fallback and turns into a second live system, so the extension buys comfort and pays for it in divergence.

If some dual entry is genuinely unavoidable, name the class in writing rather than leaving it to judgement: card payments taken at the counter, say, and nothing else. Put an end date on that sentence and keep the affected record IDs in one file. A narrow exception with a date is a plan. Use-whichever-is-quicker is not.

Pick the event first, then look up which date it falls on

A parallel period ends when you have evidence the new system can do the whole job, and the whole job is not spread evenly across the month. Most of the risk sits in four or five events that happen once per cycle, which is why a duration in days is the wrong unit.

The events worth waiting for, in the order they usually matter:

A month-end close run entirely in the new system, including the corrections that arrive a week or two afterwards rather than on close day. The close is where the system is asked for totals instead of records, and totals are where quiet import errors surface.
Payroll, from entry through to the adjustment that follows it. More people check payroll than check anything else in the month, so a failure there is expensive in trust as well as in hours.
Your slowest recurring object, all the way round once. Look at your own data rather than guessing, and find the longest-lived open record you have. If quotes routinely sit open for 90 days, whether a quote raised in the old system converts correctly in the new one cannot be answered in November when the quote was raised in September.
Every scheduled job, once each. That covers the report that only runs on the 1st and the reminder that fires 30 days after an invoice date. Scheduled things do not report themselves broken. They simply do not happen.

Now put dates on that. Cutover on 3 September plus a flat 30 days ends the window on 3 October, somewhere in the middle of the first close the new system has ever done. Follow the events instead and the September close finishes around 8 October, the corrections to it land near the 15th, and the honest end of the parallel period is the third week of October. Six weeks, not four. The difference is one extra month of one subscription, which is a smaller number than any of the alternatives.

The old system's meter is not the only one running

Deciding to keep the old system is not the same as deciding what to keep paying for, and the lever is usually seats rather than months.

Whether you can pull that lever at all is set by the plan you are already on, and Google Workspace states the difference plainly. On the Flexible Plan you can remove users "At any time (reduces monthly cost)". On the Annual/Fixed-Term Plan you can remove them "Only when you renew the contract. Until then, you pay for all purchased licenses" (Google Workspace admin knowledge base, checked 4 September 2026). On the second of those, a longer parallel period costs nothing extra, because the seats are bought either way. On the first, dropping from fifteen seats to one admin seat the week after cutover changes the shape of the entire question.

Cutting the old system down to a single admin seat has a second effect that matters more than the money. Staff cannot dual-write into a system they can no longer log into, and enforcing read-only by removing access works better than enforcing it by announcement.

The satellites keep their own meters running. Shopify's guidance on pausing a store is blunt about it: "All apps remain active when you pause your store. If you want to stop app charges, then uninstall your apps before or immediately after pausing" (Shopify Help Center, checked 4 September 2026). Pausing or downgrading a platform does not pause the six things billing alongside it, and those charges arrive on their own cycles.

One date overrides all of this. Where the old contract carries a notice period, the decision about the parallel run has to be taken before that deadline rather than at the end of the run, because sliding past it can commit you to a full further term of the thing you are leaving. That is the distinction in the cancel-by date is not the renewal date, and it is the one place where an event-driven schedule has to bend back around a calendar.

Downgrade, pause and cancel each lock something different

Downgrade instead of cancelling gets repeated as general advice. It is not general. It is four questions to put to the vendor's own tier documentation, and the answers vary so much that two vendors in the same category can behave in opposite directions.

Does the cheaper tier still display the history. Can you still export from it. Will the price you had be available if you come back. And does anything start a deletion clock.

A downgrade can be destructive. Slack's page on the free version says you are "limited to the most recent 90 days of message and file history", that messages beyond that limit are revealed again if you upgrade, and that "all data in your workspace that's more than one year old will be deleted" (Slack Help Center, checked 4 September 2026). The same page dates that deletion: "Starting August 26, 2024, we'll begin deleting messages and files more than one year old from free workspaces". It is a clock that has been running for two years already, not one that starts on the day you downgrade. Downgrading a workspace in order to keep it readable therefore achieves the reverse of the goal.

A pause can cost you your old price. Shopify's Pause and Build plan runs a store at a reduced subscription fee, and the help page does not print the figure, so take the number from the pause screen in your own admin rather than from a third-party article about it. What the page does state is that "your checkout is deactivated across all sales channels, such as the Point of Sale channel", and that "When you decide to unpause, you'll need to select a new plan as your old plan is no longer valid" (Shopify Help Center, checked 4 September 2026). If you are sitting on legacy pricing, that last sentence is the whole decision.

A cancellation can be gentler than either. Intuit's documentation says that when you cancel a QuickBooks Online subscription "you have read-only access to your QuickBooks Online data for one year", and that you can export to Excel or to a desktop version of QuickBooks up to a year after you cancel. Cancelling during a trial gives 90 days instead (Intuit QuickBooks support, checked 4 September 2026). A free year of read-only access is a better fallback than most paid tiers give you.

And a cancellation can be a wall. Xero's published answers describe cancelling as giving "one month's notice from within your Xero account", after which "data in that subscription will be archived and held in the Xero platform in accordance with our data retention policy. While archived, data held within the subscription cannot be accessed by anyone" (Xero common questions, checked 4 September 2026). The same page puts a number on how long that lasts: "you will still be able to get access to the data in the future for up to seven years, unless you request it to be deleted". Getting back to it is done "by reactivating the relevant subscription", which is standing the subscription up again rather than logging in. On that shape of vendor the notice month is the last reading window you already own, and the parallel period ends when it does whether you are ready or not.

Two accounting products, opposite answers, and neither answer is guessable from the pricing page. This is product behaviour as each vendor documents it rather than a reading of your agreement, and where a tier page and a contract disagree the contract governs and the question belongs with someone qualified to answer it.

What has to be true before you stop being able to go back

Rollback rarely ends with a decision. It ends by drift, on an ordinary Tuesday when enough real work exists only in the new system that going back would mean losing it. Nobody notices that day while it is happening, which is the reason to name it in advance.

Four conditions, and only one of them is work.

The event has completed. Not the cutover, the event from the list above, corrections included.

The verification passed on records rather than counts. Take five specific records, including the oldest one and the one with the most attachments, and open them from the new system and from the export file side by side. Matching totals prove considerably less than one attachment that opens.

The old system's own access log shows nobody has been in it. Most vendors expose last-active or login data to admins, and two silent weeks is better evidence than a team meeting, where everyone says yes to be safe. If the vendor does not expose that report, write that down too, because you will not get a second chance to find out.

An archive exists that does not depend on the vendor account. This is the condition that gets deferred, because while the login still works nothing feels urgent, and it is the only one that stops being achievable the moment the account closes. What that archive has to contain to still open years from now is a job of its own, and it belongs inside the parallel period rather than after it.

The same plan, written out with dates on it once

Events first, then the calendar. Worked through for a cutover on Thursday 3 September, the dates land like this:

3 September, evening. Freeze. The old system becomes read-only by policy. Counter payments are the single named exception and they end on the 5th.
8 September. Old system cut to one admin seat where the plan permits it. Everyone else loses access, which holds the freeze better than the announcement did.
15 September. Notice decision, taken from the contract rather than from progress. The only date here that somebody else set.
1 to 8 October. September close, run entirely in the new system.
To roughly 15 October. Post-close corrections, plus the first run of the monthly report and the 30-day reminders.
16 October. Archive taken, then verified by opening files rather than by opening the application.
17 October onwards. Downgrade, pause or cancel, according to what those four questions actually returned in that vendor's documentation.

Two of those dates came from a calendar. The rest came from the work, which is the entire argument: a parallel period ends when the new system has done everything the old one used to do at least once, and that is not a number of days.

Verified against Google Workspace, Shopify, Slack, Intuit and Xero documentation on 4 September 2026. Those five carry the examples because each one writes down how its own tiers behave, which is rarer than it ought to be. It is not a ranking: four of the five are quoted above saying something inconvenient about themselves, and the fifth hands out a year of read-only access for nothing. One number is deliberately absent. Shopify calls the Pause and Build plan "a reduced subscription fee" and never prints the amount, so this page does not print one either. Read it off the pause screen in your own admin, where it is right for your plan and your country. Tier pages get rewritten without changelogs, and a downgrade that was safe last quarter stops being safe without announcing it, which is why every claim above is a quotation with a date beside it. Anything that no longer matches its source belongs on the contact page.