How to Cancel a SaaS and Migrate Off It: Notice Deadlines, Data Export, and Parallel Runs

Hello, this is Ryuta Hamamoto from TIMEWELL.

Once you have decided to cancel a SaaS and rebuild the function yourselves, the first thing you run into is not a technical wall. It is a date. Annual SaaS contracts often carry an auto-renewal clause, and stopping it requires notice by a fixed day before the renewal date. Miss that day by one and you pay for another full year of a service you had planned to stop using.

Few companies have much practice at switching. In a 2022 report, the Japan Fair Trade Commission surveyed 548 IaaS and PaaS users among companies with annual sales of at least 5 billion yen. Only 15.7 percent had switched cloud providers in the previous ten years. Asked what they would do if their current service went up 5 to 10 percent, just 14.1 percent of those who gave a definite answer said they would move to another service or back on-premises.¹ Those numbers are not about SaaS alone, but it is fair to assume that few people inside any given company have run a cancellation and migration before.

This is the fourth article in a five-part series on cancelling expensive SaaS and bringing the work in-house. Whether to cancel at all is covered in part 1, the decision criteria, and the total cost of building versus staying is in part 3, the five-year cost model. This one is about the steps after the decision: the notice deadline, getting your data out, migrating it, the parallel run, and confirming deletion afterward. A schedule worked back from the renewal date comes at the end.

One caveat up front. Everything here about contract clauses and law is general. Terms differ by provider and by contract, so check your own agreement with your legal team before acting on any of it.

The real deadline is 30 days before renewal, not the renewal date

Take one published master agreement from a major SaaS provider as an example.² Unless the order form says otherwise, subscriptions renew automatically for one-year terms, and they stop only if one party gives the other written notice, email acceptable, at least 30 days before the end of the term. So the practical deadline is not the renewal date. It is 30 days earlier. If you renew on April 1, the deadline lands at the very start of March.

The same agreement has two more clauses that are easy to miss. The first is about fees. Fees are based on the subscriptions purchased, not actual usage; payment obligations cannot be cancelled and fees are not refunded; and quantities cannot be reduced during the term. Unused accounts keep costing money until the term ends.

The second is the back half of the renewal clause. Any renewal in which subscription volume or subscription length has decreased from the prior term is re-priced at renewal, without regard to the prior term's per-unit price. Promotional or one-time pricing also renews at the list price in effect at the time.

Put those together and you can see why a common halfway plan, keeping a handful of licenses for read-only access before shutting everything down, may not save as much as you expect. The moment you cut the quantity, the discount you had may disappear. Keep a smaller plan or cancel outright? Get the renewal quote first, then compare.

Alongside the deadline, check how notice has to be given and to whom. Does it have to be in writing, is email enough, or is there a cancellation flow in the admin console? What is the notice address in the contract? If you bought through a reseller, the notice may need to go to the reseller instead. Whatever the route, keep evidence that the notice arrived.

One more thing: the contract in your drawer may not be the current one. Where a SaaS is governed by online terms, the provider may have revised them. Japan's Civil Code, Article 548-4, allows the party that prepared "standard terms" (uniform terms drafted for transactions with an unspecified number of counterparties) to change them without individual consent if the change is in the other side's general interest, or if it is reasonable in light of its necessity, the appropriateness of the new terms, and similar factors. In return, the provider must set an effective date and publicize the change and the new terms online or by other appropriate means.³ Whether a particular B2B SaaS agreement counts as standard terms is decided case by case. Either way, read the version in force today and its change history, not the one you signed years ago.

Test the data export before you decide to cancel

After the deadline, the thing that bites is getting your data out. Japan's IPA (Information-technology Promotion Agency) publishes a guide to using cloud services safely for small and mid-sized companies, updated in June 2026. Item 13 on its checklist is "secure your data at the end of use," and it asks you to confirm the return of all data or download to your own machines, data compatibility and portability, complete erasure of residual data, and a guarantee that no other user can reuse it.⁴

In the example agreement, if the customer asks within 30 days after termination, the provider makes the data available for export or download. After those 30 days the provider has no obligation to keep it, and it is deleted.² Thirty days sounds like enough. It isn't, if the first time you try an export is after termination and you find that attachments are missing or the change history did not come along. By then you can no longer run the business on the old system.

So run an export once, on the full production data set, before you decide to cancel. At a minimum, these are the five things I would check:

What to check	What happens if you miss it
Do exported record counts match the counts in the application?	Part of the data goes missing and nobody notices
Do attachments come out with the records?	Only the text moves; receipts and drawings stay behind
Do change history, comments, and approval records come out?	You cannot reconstruct what happened during an audit or inquiry
Do users, org structure, and permissions come out?	You rebuild who-can-see-what from scratch in the new system
Are character encoding, date formats, and field meanings clear?	Garbled text and shifted dates appear on import

That list is not copied from any public guide. It is what I think needs checking.

Trouble getting data out is not unusual. The Fair Trade Commission's report quotes a user who said that groupware "was difficult to take data out of, so once you start using it, changing services is not easy, and there were cases where we had no choice but to accept a price increase." In the survey of IaaS and PaaS users, some respondents also named the cost of extracting data, and the need to reformat it because old and new services use different formats, as factors that make switching hard.¹

Government policy asks you to look at this at the point of entry. The Japanese Digital Agency's standard guideline DS-310 tells agencies to avoid vendor lock-in by choosing cloud services that meet conditions such as guaranteed data portability and a published, reasonable pricing structure.⁵ Ideally you check this before signing. If you are already thinking about cancelling, now is the time to check.

Companies that have an EU entity contracting for SaaS there have one more right to draw on. The EU Data Act has applied since September 12, 2025. It requires PaaS and SaaS providers to make open interfaces available and, at a minimum, to export data in a commonly used, machine-readable format. From January 12, 2027, providers can no longer charge switching fees, including data egress charges.⁶ According to a law firm's analysis, contracts must also let the customer start switching on no more than two months' notice, with the switch completed within at most 30 days after the notice period ends.⁷ The rules cover services provided to customers in the EU, so they will not necessarily apply to a contract signed by a head office in Japan. Ask your legal team whether they apply to you.

Migrate less, and plan for late surprises

How do you get the exported data into the new system? IPA's "User Guide to Successful System Rebuilding, 2nd Edition" is useful here. It is not written about leaving SaaS, but what it says about planning data migration applies directly.⁸

The guide starts by warning that if data migration planning starts late, it can hit the overall project plan and even the budget. There are many things to confirm in advance, such as what to migrate and the record layouts, and data cleansing (fixing invalid values and duplicates) takes time. It then lists six areas where problems tend to occur: scoping what to migrate, confirming layouts, cleansing, mapping character encodings, choosing the migration method, and verifying the results.

The one I think pays off most is the first, scoping. The guide says migrating everything increases the workload, time, and cost, so it is better to narrow the scope, and gives as an example setting a clear policy such as discarding data more than three years old or transactional data. A SaaS you have used for years has piled up years of history, and you will not use all of it day to day in the new system. Move the last few years and anything still active, and leave older data as exported files in read-only storage. That alone cuts both conversion and reconciliation work a great deal. For records with legally or internally mandated retention periods, though, make sure you can actually find and retrieve them from that storage when needed.

The guide also says that problems caused by data migration surface late in development, so time to resolve them should be built into the plan. Unexpected values, and fields being used in ways you could not see on screen, only appear when real data flows through. Do not assume one migration rehearsal is enough. Schedule at least two.

The difficulty shows up in the numbers, too. In IPA's DX Trends 2025 survey, 334 Japanese companies that were bringing development in-house were asked about their challenges. "Hard to hire or develop people" stood out at 82.3 percent, and 19.5 percent said "moving externally developed systems in-house is difficult."⁹ Migration is one of the most people- and experience-hungry parts of insourcing. If you cannot staff it internally, getting outside help for this step alone is a sensible call.

Finish the parallel run inside the term you have already paid for

Once the new system works, you run the same operations on both the old SaaS and the new system for a while and compare the results. That is the parallel run. IPA's rebuilding guide lists it as a post-release risk measure: performing the same operations on both the current and new systems for a period to flush out faults. It flags two cautions. The business side's workload goes up, so check how much parallel running they can tolerate. And check whether it can be done before the current system's end of life or end of support.⁸

For a SaaS, that end-of-life date is simply the contract end date. That leads to the sequence I recommend: run the parallel test inside the last contract term you have already paid for, and reach a conclusion before the cancellation notice deadline. If, as in the example agreement, fees are based on seats purchased rather than usage and are non-refundable, continuing to use the old SaaS during that period costs nothing extra. If instead the notice deadline arrives mid-run, you are left with two bad options: give notice without knowing whether the new system holds up, or renew for another year just in case.

How long should it last? I could not find a public benchmark. My rule of thumb is one full business cycle at minimum. If the work has a month-end close, put one close through both systems; if there is a quarterly roll-up, put that through too. It is common for daily entry to work perfectly while the closing process alone produces a different result.

Before the duration, decide the exit criteria. The rebuilding guide points out that with vague completion criteria you cannot judge when testing is done, and it can drag on indefinitely, especially in tests that compare old and new results. It recommends setting quantitative criteria for business continuity and agreeing on them with stakeholders before starting.⁸ Write down something like "closing totals match between old and new," "record counts for the same period match," and "any difference can be explained," before the parallel run begins. Knowing when double entry will end also makes the extra workload easier for the business side to accept.

Appendix: a cancellation and migration schedule worked back from renewal

Here is everything above as a schedule counted back from the renewal date. It assumes a notice deadline 30 days before renewal and is only one example; how long each step takes depends on your data volume and your contract. If your notice period is different, shift the dates accordingly.

When (relative to renewal)	What to do	Main owners
6 months before	Collect the contract, order forms, and current online terms. Confirm the renewal date, notice deadline, notice method and address, and data-return clause. Start a data inventory and decide what to migrate versus only archive	Procurement, legal, IT
5 months before	Test a full export of production data and reconcile counts, attachments, history, and permissions. Start the prototype of the replacement	IT, development
3 months before	First migration rehearsal and fixes for inconsistent data. Set the parallel-run exit criteria and agree on them with the business side	IT, business users
75 to 40 days before	Parallel run covering one full business cycle, such as a month-end close. Second rehearsal to lock down the import procedure	Business users, IT
40 days before	Judge against the exit criteria and decide internally whether to cancel. Compare with the quote for renewing at reduced volume	Management, IT, procurement
A few days before the notice deadline (30 days before)	Send notice by the required method and keep proof of delivery	Procurement, legal
By the day before renewal	Final export and import, and user cutover	IT
Within 30 days after termination (in the example contract)	Final check for anything missed in the export. Assume nothing can be retrieved after this window	IT
After termination	Confirm deletion of residual data. Shut off integrations, remove accounts and authentication settings, and confirm billing has stopped	IT, finance

Some of you will look at this and realize the next renewal is less than six months away. In that case, I think it usually ends up cheaper to aim for the following renewal and start with the export test now, rather than forcing a cancellation this term. Cut the parallel run short to hit this year's deadline and the cost lands on the business users after cutover.

The last two rows are the work people forget. IPA's guide includes complete erasure of residual data, and a guarantee that no other user can reuse it, in its end-of-use checklist because cancelling does not automatically mean the data disappears.⁴ Some providers, like the one in the example, state that data is deleted after a grace period, but how a customer can confirm when that happened varies by contract. Can they issue a deletion certificate? If not, how will you confirm it? Ask before you send the notice.

Security standards now look at this step as well. JIS Q 27001:2023, Japan's version of ISO/IEC 27001:2022 and the certification standard for an ISMS (information security management system), added control 8.10, "information deletion," to Annex A.¹⁰ If you run an ISMS, cancelling a SaaS is also a moment to record evidence against that control. At the same time, switch off single sign-on settings, API keys, and automated feeds from other systems that pointed at the old SaaS. Leave them in place and some other system will keep trying to push data to a service you thought you had cancelled, producing errors that are hard to trace.

What our FDE service can do

TIMEWELL provides an FDE (Forward Deployed Engineer) service. An FDE is an engineer who goes into the client's workplace and turns the problem into working software. SaaS cancellation and migration is, in my view, a step where the way an FDE works fits naturally.

In terms of the schedule above, we work alongside you on the technical steps from the export test through the final import. The decision to cancel and the notice to the provider stay with you. We build the tooling to export all production data and reconcile counts and attachments, run a prototype of the replacement on data with personal information and similar details masked, write the conversion and cleansing logic, and set up automatic comparison of old and new results during the parallel run. Working with the business side to put numbers on the parallel-run exit criteria is also part of the job. We box the engagement at roughly 45 to 90 days up front and agree on the exit conditions before we start.

Where and how to host the replacement is covered in part 5, designing business apps in your own cloud tenant. Which work to consider bringing in-house in the first place is the subject of part 2. For how an FDE engagement runs from start to finish, see the FDE service page.

How this differs from contract development

There is one thing to watch when you hand migration to an outside firm. Part of the point of leaving a SaaS is to reach a state where your operations do not depend on one vendor. If the migration leaves behind something only the migration contractor can maintain, you have just swapped one dependency for another.

That is why we treat FDE work as distinct from contract development. In contract development, hours are revenue, so the longer the parallel run and the more rework, the more the contractor earns. We price by period rather than by accumulated hours, and we do not write contracts that reward running long. We treat our hours as an investment in making the next engagement faster. Pieces that work for other companies too, like export reconciliation and old-versus-new comparison, become components of our products and get reused, while procedures unique to your company stay as your configuration. And we define the ending at the start: when your own staff can fix the migrated system and export their own data, our job is done.

What we do and where it stops

Let me be straight about the limits. First, contract negotiation and legal judgment are not our role. We can help pull the renewal date and notice deadline out of the contract and put them into a schedule, but how to read a clause and how to negotiate with the provider belong to your legal team and, where needed, your lawyers. The cancellation notice itself comes from you, as the party to the contract.

Second, data that cannot be exported cannot be exported by us either. Information that the SaaS export function or API does not cover has to be copied by hand from the screen, or given up. That is one more reason to run the export test early: so you can make that call early.

Third, if our work on the migration involves handling personal data, we become your contractor for that processing. Under Article 25 of Japan's Act on the Protection of Personal Information, a business that entrusts the handling of personal data must exercise necessary and appropriate supervision over the contractor.¹¹ We hold ISO/IEC 27001 certification (scope: planning, development, and provision of SaaS products using AI technology), but that does not remove your duty to supervise. We agree on the processing contract and the scope of data we touch before any work begins.

Nor do I think every SaaS should be cancelled. For work like accounting and payroll, which has to keep pace with changes in law and accounting rules, leaving it to a SaaS or a package is often the more rational choice. The steps in this article are also assembled from public guidance and published contract terms, not from a specific client engagement. Finally, capacity: we are a small company, and there is a limit to how many sites we can be at at once.

Summary

Plan a SaaS cancellation and migration backward from the renewal date. Four things matter most:

• The notice deadline sits before the renewal date. In the example contract it is 30 days before, and a renewal at reduced volume is re-priced
• Test the data export on the full production set before you decide to cancel. The post-termination window in the example contract is only 30 days
• Migrate less, and schedule two rehearsals on the assumption that problems surface late
• Finish the parallel run inside the last term you have already paid for, against criteria you set in advance

None of this is glamorous. But the money you expect to save by leaving a SaaS moves a full year out if you miss one notice deadline. Start by opening the contract and putting the renewal date and the notice deadline on your calendar.

If you are looking for someone to work through cancellation, migration, and the parallel run with you, take a look at the FDE service page or book an FDE consultation. If you want to revisit whether to cancel at all, go back to part 1 of the series, the decision criteria.

Footnotes

1. Report on the Actual State of Transactions in the Cloud Services Sector (Japan Fair Trade Commission, June 28, 2022). Switching experience and responses to a price increase are on pages 49 to 50 (survey of 419 IaaS users and 129 PaaS users, July to August 2021); factors that make switching difficult are on page 52; the user comment on groupware price increases is on page 92. See also the press release. In Japanese; quotations are my translation ↩ ↩²

2. Based on the fees, subscription term, and customer-data return clauses in a master services agreement published by a major SaaS provider (English version dated September 1, 2026; Japanese version last updated June 1, 2026). The provider's name and a link are omitted because the aim is not to assess any particular vendor. Terms vary by provider and by contract ↩ ↩²

3. Civil Code (Act No. 89 of 1896), Article 548-2 (agreement to standard terms) and Article 548-4 (changes to standard terms). e-Gov statute database, in Japanese ↩

4. Guide to the Safe Use of Cloud Services for Small and Medium-Sized Enterprises (IPA, June 2026). Checklist item 13, "Secure your data at the end of use" (page 27), in Japanese ↩ ↩²

5. DS-310 Basic Policy on the Appropriate Use of Cloud Services in Government Information Systems (Digital Agency, May 27, 2025). Section 3.3 on vendor lock-in (page 12), in Japanese ↩

6. Data Act explained (European Commission). The date of application, export requirements for PaaS and SaaS, and the removal of switching charges are from this page ↩

7. EU Data Act: Significant New Switching Requirements Due to Take Effect for Data Processing Services (Latham & Watkins, August 19, 2025). The maximum notice and transition periods are from this analysis; I have not verified the article numbers in the regulation itself ↩

8. User Guide to Successful System Rebuilding, 2nd Edition (IPA, February 2018). Test completion criteria on page 114; Table 3.9, examples of risk measures including the parallel run, on page 115; Section 3.8 on data migration planning and Table 3.11 on pages 119 to 121. In Japanese; quotations are my translation ↩ ↩² ↩³

9. DX Trends 2025 (IPA, June 2025). Figure 2-16, challenges in bringing development in-house (page 45; FY2024 survey; Japanese companies bringing development in-house, n=334). In Japanese ↩

10. ISMS User's Guide (JIPDEC, JIP-ISMS111-4.0, March 31, 2025). Table A-2, added controls (page 74), in Japanese ↩

11. Act on the Protection of Personal Information (Act No. 57 of 2003), Article 25 (supervision of trustees). e-Gov statute database, in Japanese ↩