The date that actually matters
It is not the day the software stops working. It is the day your data is deleted, which comes later and is therefore easy to file under "deal with it after". Freshworks, retiring Freshteam, gives paid customers 90 days after their subscription ends to download their data and then says plainly: "The account data will be deleted post 90 days for Paid accounts cancellation and 14 days for Free account cancellation." Whatever system you are on, find that sentence in your vendor's notice and put the date in a calendar before you read anything else.
Short answer
Find your deletion date first — it is the only irreversible one, and it falls after the shutdown, which is why it gets missed. Export everything before you shortlist a replacement: the full account export, then each module separately, then the actual document files rather than the links to them, then screenshots of the settings that do not export at all. Cut over immediately after a pay run, not before one, and check every leave balance by hand once.
Written by
Subhan Khan, Founder
·
·
Migration
Software you depend on gets retired. It is not a betrayal and it is usually not sudden — the vendor writes to you, sets out dates, and gives you a window. What makes it painful is that the window is spent on the wrong thing: most of it goes on choosing a replacement, and almost none on getting the data out. Then the export turns out to be partial, and the parts that did not come across are the parts you needed.
Read the notice for three dates, not one
Vendor notices bury the useful dates among the reassuring ones. Freshworks' sunset FAQ is a good worked example because it is unusually specific, and the same four questions apply to any notice you receive.
- When does billing stop? For Freshteam, 7 March 2026 ended free accounts and cancelled half-yearly and annual renewals, while monthly renewals carried on. All renewals stopped on 7 June 2026. Note the gap: a single "renewals ended in March" summary is wrong for anyone who was paying monthly.
- When does access stop? Freshteam "will remain accessible for 90 days after your subscription end date". That is measured from YOUR subscription end, not from a date the vendor publishes — so two customers reading the same notice have different deadlines.
- When is the data deleted? Ninety days after expiry for paid accounts, fourteen for free ones. This is the only truly irreversible date in the notice.
- Is there a refund? For Freshteam, no: "customers can use the product until they complete the current subscription period." Worth knowing before you plan a cutover that leaves paid time unused.
Write your own four dates down before you look at a single alternative. A replacement chosen calmly against a known deadline is a better decision than a replacement chosen in the last fortnight, and the deadline is the part you do not control.
Export everything, before you have chosen anything
This is the step people postpone, and it is the only one with a hard deadline. You do not need to know where you are going to take your data with you. Export first, evaluate second — the export is worthless the day after deletion and the evaluation is not.
Take the vendor's own full export first
Most systems have a single account-level export that produces far more than the per-screen CSV downloads do. In Freshteam it sits under Admin settings, then account, then export account data. Run it, download it, and check the file actually opens before you treat the job as done. Then run it again a week later: an export taken while somebody is still tidying records is a snapshot of a mess.
Then export each module separately anyway
The account export is usually structured for the vendor's convenience rather than yours, and often flattens things you will want separately — employees, leave balances, absence history, documents, candidates, offers. Pull each as its own file. Duplication costs you disk space; a missing table costs you the record.
Download the documents, not the links to them
Contracts, right-to-work evidence, signed policies and offer letters are usually stored as files with a database row pointing at them. A CSV export gives you the row. When the account closes, the file behind the link goes with it, and you are left with a spreadsheet full of URLs that resolve to nothing. Download the actual files, in bulk if the system allows it and by hand if it does not.
Screenshot what you cannot export
Some things have no export at all: approval chains, workflow configurations, permission matrices, the shape of your own custom fields. These are not data so much as decisions, and re-deriving them later from memory is how a migration quietly changes your process. A folder of screenshots is an unglamorous but entirely adequate record, and it takes an afternoon.
Store the lot somewhere that is not the system you are leaving and not one person's laptop. This is personal data about your staff, so it belongs somewhere with the same access controls your HR system had — not in a shared drive that the whole company can browse.
What usually does not come with you
Assume these are lost unless you check
Every migration loses something. The question is whether you find out during the move or eighteen months later when somebody asks for it. These are the five that go missing most reliably.
- Historical approvals. Who approved which leave request, and when. Most systems export the resulting balance, not the decision trail behind it. If you are ever asked to show that a request was properly authorised, the balance will not answer the question.
- Audit trails. The record of who changed what and when is typically internal to the platform and has no export path at all. If you have a retention obligation that depends on it, raise that with the vendor while you still have an account and somebody to ask.
- Document links. Covered above, and worth repeating because it is the one that looks fine in the export file and fails later. The link survives the migration; the file does not.
- Custom fields. Anything you added yourself tends to arrive as an unlabelled column, or not at all. Export the field definitions as well as the values, or you will be guessing what "Field 7" meant.
- Anything a manager wrote. Notes on a record, return-to-work comments, probation observations. These are often stored as free text attached to an object the export does not include, and they are frequently the most useful thing in the system.
Decide deliberately what you are willing to lose. Some of this genuinely does not need to move, and pretending otherwise turns a two-week migration into a three-month one. But make it a decision rather than a discovery.
Sequencing a cutover around payroll
The single worst time to switch HR systems is the week payroll runs, and the second worst is the week before. Payroll depends on data that changes in the HR system — starters, leavers, absence, contractual changes — and a cutover mid-cycle means some of those changes live in the old system and some in the new one.
- Pick the boundary, not the date. Cut over immediately after a pay run has been approved and paid, not on a calendar date that happens to be convenient. That gives you the longest possible clear run before the next one.
- Freeze changes for a short, announced window. From the final export to the new system going live, nothing changes in either. A day or two is usually enough, and telling people beforehand costs nothing and prevents most of the mess.
- Run the first cycle from the new system with the old export beside you. Not in parallel in the old system — that is twice the work and creates two versions of the truth — but with the exported figures open, reconciling as you go.
- Check leave balances by hand for everyone, once. Balances are the thing that migrates wrong most often and the thing employees notice fastest. A spreadsheet comparison of old against new, before anyone logs in, is a couple of hours that saves a fortnight of disputes.
- Keep the old export available for at least a full leave year. You will need it for the first year-end, for any query about a historical request, and for the audit you are not expecting.
If your payroll is run by an accountant or a bureau, tell them the cutover date before you set it rather than after. They may have a view about timing, and it is cheaper to hear it in advance.
What to check in the replacement contract
You are in this position because a vendor decided to stop. That can happen again, and the contract is the only place you get any say in how it goes when it does. Five things worth reading before you sign the next one.
- Notice period for discontinuation. How long must they give you before switching the product off? If the contract is silent, the answer is whatever they decide at the time.
- A data-export right that survives termination. Specifically: for how long after the account ends can you still get your data out, and in what format? "You can export at any time" is not the same promise once your account is closed.
- What "export" actually includes. Ask for it in writing, by module, including documents and audit history. The gap between what a vendor calls a full export and what you would call one is exactly the gap this post is about.
- What happens on acquisition. Products get retired most often after the company is bought. A clause about assignment and continuity is worth more than a clause about uptime.
- Deletion timing, stated as a duration you control. Ninety days is generous. Fourteen is not much. Either way you want it written down rather than announced to you later in an email.
None of this makes a vendor keep a product alive. It makes the ending orderly, which is the most a contract can realistically do for you here.
The short version
Find the deletion date and put it in a calendar. Export everything before you shortlist anything, including the documents and the things that do not export cleanly. Decide what you are willing to lose rather than discovering it later. Cut over just after a pay run, freeze changes for a day or two, and check every leave balance by hand once. Then read the next contract for what happens when this repeats.
For what it is worth: we make HR software — HRMZY — and we would rather you chose it on the merits than in a panic in the final fortnight. Our sourced price comparison against the platforms most people shortlist is here, with every figure dated and the headcounts where a competitor beats us marked: the full comparison.
Sources
Every date and figure about Freshteam above is quoted from the vendor's own sunset FAQ, linked beside it. Two figures that circulate widely — a company count, and an end-of-service date in 2027 — are not in this post, because neither appears on that page. Oldest reading here: 12 September 2026.
Dates and terms are the vendor's and can change. If you are reading this well after the date above, check the FAQ itself before acting on anything here.