A HubSpot auto renewal date is either a cliff or a project, and the only thing that decides which is whether the calendar runs backward from it. Run forward, from the day someone decides to leave, it is a list of things to build and a date that keeps getting closer. Run backward, from the day the contract ends, it is a short list of things that cannot be done afterward, a longer list that can, and a cutover placed early enough that the old portal is still there if something breaks.
This guide is the backward version. It comes from one exit. A small B2B software company, a lean marketing team, $14,000 a year, and a contract end date that was fixed before we opened the portal. Every date below is given as T minus, counted back from the day the contract ended, because the shape of the calendar is the point and the dates themselves are the client’s.
What actually happens on the HubSpot auto renewal date if you leave
Less than most people fear, and one thing more than they plan for.
HubSpot does not disappear. The portal drops to the free tier. The contacts, companies, deals and tickets stay in it. The API stays reachable. Nothing in a well-built exit requires the company to renew or reactivate a paid subscription, and on this engagement that was written into the signed scope as a plain statement of fact.
The one capability that genuinely ends is Marketing Hub email sending. On the date the automated chain stops, and every link in every email the portal ever sent, which on this portal was routed through a HubSpot-hosted sending subdomain, stops resolving the moment that subdomain is pointed elsewhere.
That asymmetry is the whole calendar. The CRM side of an exit has a soft landing: the data is still there three months later if you missed something. The email side has a hard one. If the new sender is not carrying the program on the date, the program is off, and the reputation a new sending domain needs takes weeks to earn and cannot be bought faster. Every date in this guide is placed by that one fact.
The dividing line is not hard versus easy
Most exit plans sort the work by difficulty. It is the wrong axis. The architecture memo on this engagement put it in one line we have used on every exit since: the dividing line is not hard versus easy, it is dies-with-the-portal versus does not.
Dies with the portal, on this one: the suppression and bounce history, including the addresses that belonged to deleted contacts; the spam and territory rules that existed only inside two workflows’ enrollment criteria; the pipeline stage labels and their order; a custom object holding 98 contract records and the 50 renewal dates someone had typed in by hand; every file attachment, which is in no CSV export; the HTML of 442 marketing emails; the definitions of 90 workflows; and a restore of the archive that a named person has actually opened. 1 See also 1 See Dies With the Portal: Seven Things a HubSpot Export Will Not Give You, for what is on the extraction list and why each item is unrecoverable afterward.Read Dies With the Portal: Seven Things a HubSpot Export Will Not Give You That list became the first phase of the signed scope, and it carried a note beside its date that no other phase carried: cannot be done after the contract ends.
Does not die: the four reports anyone actually looked at, which can be rebuilt once someone asks for them; the long tail of website content and its redirects; the bridges to other systems; the re-permissioning of contacts whose consent is unclear. All of it can follow the date, and on this engagement most of it was left outside the fixed scope to do exactly that.
A plan sorted by difficulty front-loads the website because it is the biggest piece. A plan sorted by mortality front-loads a week of extraction that produces nothing a CEO can click on, and that week is the one that cannot be bought back.
Week zero is extraction, not build
The architecture for this exit was written 46 days before the contract ended. It scheduled the week that followed as week zero: extractions and applications, no build work. Day one was the contact-level suppression export. Day two was the rules inside the workflows and the pipeline stage labels. Nothing in that week needed a decision from the client or a line of code.
Week zero did not run. The internal notes written a week later say so in plain words: nothing in the record showed the suppression export, the rules files or the stage labels had been pulled, and the week’s work was all audit refinement. The plan was still correct, because the first contracted phase already held every one of those items. What had changed was that there was no buffer left in front of it.
A plan sorted by difficulty front-loads the website. A plan sorted by mortality front-loads a week of extraction that produces nothing anyone can click on, and that week cannot be bought back.
The lesson is about sequence, not speed. Extraction is the only work in an exit that gets no easier with time and cannot be rescheduled past the date. Everything else can. So it goes first, before the proposal is signed if at all possible, because the day the extraction is done is the day the calendar stops being a cliff.
Why does the email warm-up have to start inside the contract?
Because a sending domain’s reputation is earned at a rate nobody controls.
The company’s marketing domain had been quiet since 2023. Under Google’s bulk-sender rules, in force since February 2024, a domain that quiet is treated as new, and the planning guidance from email platforms and deliverability vendors is four to eight weeks of widening sends to reach production volume. 2 Source 2 Google Workspace Admin Help, “Email sender guidelines,” in force for bulk senders since February 2024. Senders of 5,000 or more messages a day to Gmail must authenticate with SPF, DKIM and DMARC, support one-click unsubscribe, and keep reported spam rates under 0.1%, never above 0.3%. On this engagement the plan put the first warm-up send exactly four weeks before the contract ended. The floor of the window, with nothing beneath it. 3 Editor's note 3 The four-to-eight-week ramp is planning guidance from email platforms and deliverability vendors, not a measurement. We treat it as the floor of a window and start inside the old contract so a reputation problem surfaces while the old sender is still available.
The ramp does not need to finish before the contract ends, and it will not. It needs to start early enough that a reputation problem surfaces while HubSpot is still the fallback. If the new domain lands in spam in its second week, you find out at T minus two weeks, with the old sender still paid for and still able to carry the program. If the ramp starts after the date, the same problem surfaces with no sender at all.
Two dependencies sit in front of the first send, and both belong to the customer rather than the agency. The new sending subdomains need their authentication records published, and on this engagement the DNS lived in the client’s own cloud account next to the records its product runs on, so nothing could be published until someone there was introduced. The ask to the client said it without softening: there is no default if this goes unanswered, and every day it slips comes out of the warm-up window. The second dependency is the suppression list, which loads into the new platform before a single subscriber, so the new sender never re-learns years of bounces by sending to them. 4 Definition 4 Sending-domain setup, in order: a subdomain for marketing mail and a separate one for transactional mail, never the apex; SPF, DKIM and DMARC published before the first send; the suppression list loaded before any subscriber; the ramp ordered by engagement, widening weekly.
One design decision followed from the same risk, and it costs nothing. Transactional mail (form confirmations, support replies) was split from marketing mail onto its own subdomain, so a reputation problem on the marketing side can never stop a form confirmation arriving. At this company’s volume, about two inbound leads in five months, every one of those confirmations matters.
Never cancel early
The temptation is obvious. The new platform is live at T minus three weeks, the old one costs $14,000 a year, and a prorated month looks like free money.
The signed scope on this engagement listed, among the things the client provides, no early cancellation of the HubSpot contract, with the reason attached: it is already paid for through the date, and cancelling early would end marketing email sending before the new platform is carrying it. The one capability that ends with the contract is the one you most need running until the ramp has widened to full volume and the first real send has landed.
There is a second reason, and it shapes the rest of the calendar. The old portal is the only fallback the project has. It is paid for. It is the one system in the plan known to work. Everything about where the cutover sits follows from refusing to throw that away a day earlier than the contract does.
Cut over before the last day
The cutover on this engagement was placed at T minus nine days, with a window to T minus seven for monitoring and the final three days before the date held as a sweep. The decision record gives the grounds in one sentence: HubSpot is the only fallback and it is already paid for, so a plan that needs the last day to go right has no fallback at all.
That sentence was written against two of the three candidate designs, which had cut over on or near the deadline. One put the DNS flip at T minus three days, with a self-hosted CRM stood up in 46 days and zero slack, and the review called it the weakest. The design that won was not the most elegant. It was the one with a week of slack in it.
The plan put the website live at T minus eighteen days, nine days ahead of the CRM cutover, because the site is the riskiest visible piece and deserves a real bake while the old one is still reachable. In the event it went live at T minus nine, inside the slack that existed for exactly that purpose, and the CRM and email cutover is still open behind it as this is written, inside what the slack left. That is what slack is for. A plan with none would have had the same slippage and nowhere to put it.
The final sweep, T minus three to the date, is short and mechanical. A last delta import of anything changed since the cutover. A re-run of the suppression export, diffed against the new platform, so opt-outs taken in the last three days carry across. A final checksummed export of everything, and a restore read that someone opens. The losses schedule signed in writing. Every external account, ours included, revoked. Then the contract ends, and the portal becomes a free-tier archive nobody needs to log into.
A plan that needs the last day to go right has no fallback at all. The design that won was not the most elegant. It was the one with a week of slack in it.
Two clocks that do not stop on the date
Most of the calendar counts down. Two items run on other clocks, and both are easy to miss because neither appears on a renewal invoice.
The first counts down from a date HubSpot chose. A deleted workflow can be restored from the interface within a window HubSpot documents as about 90 days. 5 Editor's note 5 HubSpot’s documentation describes a window of about 90 days in which a deleted workflow can be restored from the interface. We read it and did not test it. On this portal, four workflows that had unsubscribed, demoted or deleted contacts, 55,422 enrollments between them, had been deleted in the two months before we read the portal. For the pair deleted earliest, the restore window closed within days of the contract end. We chose not to restore them, because every suppression they had caused was already captured in the export and the only thing lost was which workflow had done what. Had the history mattered, the real deadline would have fallen days before the date, and nobody would have known.
The second counts forward from the last email the portal sends. The FTC’s CAN-SPAM compliance guide says an opt-out mechanism must be able to process requests for at least 30 days after a message is sent, and that it may require nothing more of the recipient than an email address or a visit to a single page. 6 Source 6 Federal Trade Commission, “CAN-SPAM Act: A Compliance Guide for Business.” An opt-out mechanism must be able to process requests for at least 30 days after the message is sent; requests must be honored within 10 business days; a sender may not require any information beyond an email address or any step beyond a reply or visiting a single page. Every one of the 16 live emails we exported carried an unsubscribe link and a preferences link pointing at HubSpot system paths on a HubSpot-hosted subdomain, and people were using them: seven opt-outs in a ten-day stretch between our first read of the portal and the export, about one every two days, each through the link in the email.
On this engagement the last possible HubSpot marketing send was a Tuesday at T minus three days, the nurture chain’s final scheduled run. The legal floor therefore ran to about T plus 27 days, well after the portal could honor its own links. The answer was a one-field unsubscribe page on the new site, with the old HubSpot paths redirected to it, kept indefinitely because old emails sit in inboxes for years and the page costs nothing. Underneath it sat one deliberate choice: the email subdomain stayed pointed at HubSpot until the date itself, so the opt-out links, and every tracked content link in the last three nurture sends to up to about 1,063 enrolled contacts, kept working natively to the end. Moving platforms does not move the obligation. It only moves who has to meet it.
A late signature compresses the work, not the deadline
The proposal assumed signature on a given day. It arrived three days later. Every phase date was left where it was, because the contract end does not care when the proposal was signed, and the three days came out of two places: the first phase, which was left with six working days, and the deliverability ramp, whose first send moved from four weeks before the date to about three and a half.
That is the arithmetic the renewal conversation never shows the buyer. Every day between the decision and the start of extraction is spent out of the one budget with no slack in it, and the budget is not the agency’s hours. It is the weeks a mailbox provider needs before it trusts a new sender, and those cannot be bought back at any rate.
The internal notes also recorded what to do if the signature had landed much later: not compress the ramp, but cut over later inside the remaining slack and hold the last days as the sweep, as a deliberate decision rather than a drift. The honest move when time is short is to spend the buffer on purpose and say so. The dishonest one is to keep every date and quietly delete the week that made them safe.
What you gain when the date becomes a project
The calendar turns a renewal date from something that happens to you into something you schedule, and that changes what the date is worth.
With the calendar in hand, the renewal negotiation has a floor under it. You know what dies on the date and what does not, so the vendor’s “you will lose everything” has a measured answer: one capability, and here is the week its replacement goes live. You know the warm-up takes four to eight weeks, so you know the last responsible day to decide, and it is earlier than the notice period in your contract. You can say no with a plan, which is a different conversation from saying no with a hope.
The email program comes out the other side in better shape than it went in. A sender that starts with years of bounces and complaints already suppressed, on a subdomain that cannot take the company’s transactional mail down with it, is a stronger deliverability posture than the one being paid for, and it is in place on day one rather than recovered over a quarter.
The fallback is free. For the length of the contract the old portal is a paid-for safety net under every step of the migration, and keeping it there costs nothing extra. Placing the cutover early is what converts that from a sunk cost into insurance.
And the company ends with a record. Every phase of this exit ends in a test that passes or does not, written into the scope before the work began, and the losses schedule is signed at handover. A year from now nobody argues about what was agreed, because it is written down with dates on it. To a CFO that is worth more than the month of fees a quick cancellation would have saved.
The worksheet
Work backward from your own contract end and put the dates in yourself. The intervals are from one exit, not a law; the order is the part that transfers. The sheet leaves out two things: a cancellation deadline, because your notice terms are whatever your contract says and you should read them this week, and any calendar date, because the shape is the point.
| When | What has to be true | Why it cannot wait |
|---|---|---|
| T minus 7 weeks, or as early as the decision allows | Decision made. Extraction begins: suppression history (the contact-level export and the portal-level timeline), the rules inside workflow criteria, pipeline stage labels, custom objects, file attachments, email HTML, workflow definitions. Any deleted workflow you need is restored now. | Everything in this row dies with the portal. The ramp cannot start until the suppression list is in hand. The 90-day restore window runs on HubSpot’s clock. |
| T minus 6 weeks | New sending subdomains registered, one for marketing and one for transactional, with authentication published. DNS access from the customer is the gate. | There is no default if DNS access goes unanswered. Every day it slips comes out of the warm-up. |
| T minus 5 to 4 weeks | Suppression loaded into the new platform, then subscribers. First warm-up send, engagement-ordered, widening weekly. | Four to eight weeks to production volume, and four is the floor. A problem has to surface while the old sender still works. |
| T minus 24 days | First phase accepted: a written inventory of what was extracted, someone at the company reads a record back from it, both subdomains authenticated with a test send from each. | A backup nobody has opened is a claim. This phase cannot be done after the date. |
| T minus 18 days | Website live on the new platform, redirects in place, old tracking removed. | The riskiest visible piece gets a bake while the old site is still reachable. |
| T minus 13 days | Email program rebuilt and test-sent through its full handoff. Full rehearsal: every form submitted end to end, then every leg deliberately broken to confirm the failure is visible. | A failure nobody is watching still has to announce itself before the fallback is gone. |
| T minus 9 days | CRM and email cutover. Work frozen in the old portal. New workflows switched on. | The old portal is the only fallback and it is already paid for. A plan that needs the last day has none. |
| T minus 7 days | Cutover complete. Monitor. | Slack. If the cutover slips, this is where it slips to. |
| T minus 3 days | Last possible marketing send from HubSpot. Final delta import. Suppression re-pulled and diffed against the new platform. | Opt-outs taken in the final days must carry across. The 30-day opt-out clock starts here. |
| T minus 2 days | Final checksummed export. Restore read. Losses schedule signed in writing. | After the date, the archive is the only record. |
| T minus 1 day | Every external account revoked, the agency’s included. The contract is not cancelled early. | Marketing sending must be carried by the new platform before the old one goes. |
| The date | Portal drops to the free tier. Data stays. Marketing sending ends. Email subdomain repointed. | Nothing here requires renewing or reactivating. |
| T plus 27 days, 30 days after the last send | Old unsubscribe links still land on a working one-field page. Keep it indefinitely. | The legal floor runs from the last send, not from the contract. |
If you are still deciding whether to leave, the six-factor framework comes first, and the calculator will tell you what the date is worth in dollars. If you have decided, the list of what dies with the portal is the row-one detail this calendar assumes. The calendar itself is the thing between those two: the reason a renewal date can be a project with slack in it instead of a cliff, and the reason the slack has to be put there on purpose.
The research is free. So is the diagnosis. 60 seconds →