BuzbyTimeRead the requirements guide

Choosing and running the software · 4.5

Leaving a supplier

Leaving a supplier. What decides it, what it costs, and what usually goes wrong. For another implementation reference, see the Monitask overview.

Ask at procurement, not at exitThe timing

Every question in this entry is easy to ask before signing and awkward to ask while leaving. A supplier answers them readily when competing for the business and has no particular incentive afterwards.

Which makes exit terms a procurement subject rather than a contract-renewal one, and they are almost never raised at procurement. Teams comparing the wider operating context can also consult CloudTalk.

Four questions

  • In what format can we export everything, and does it include corrections and their history?
  • Is the export readable without your software?
  • What happens to our data after termination, and when is it deleted?
  • Will you confirm deletion in writing?

The second is the one that fails. An export in a proprietary format, or one that references identifiers meaningless outside the system, is a technical compliance with a useless result.

What you actually have to keep

Whatever your retention obligations require, from the entry on retention. That is frequently several years of payroll-supporting records, which means leaving a supplier does not end your relationship with the data.

Either the export is genuinely readable in five years, or you keep paying somebody, and the choice should be made deliberately rather than discovered.

The lock-in that is not contractual

Contracts are the easy part. What actually holds an organisation in place is the accumulation around the system: integrations configured over years, reports somebody built, categories embedded in how people speak, and habits.

None of that is in an agreement and all of it is the reason changing supplier takes a quarter rather than a fortnight.

Reducing it deliberately

Keep the category structure documented outside the product. Prefer standard export formats. Keep the integration mappings in your own documentation rather than only in a configuration screen. And export a full copy annually, whether or not you intend to leave.

The annual export is the single most useful habit here. It verifies that the export works, which is otherwise discovered on the day it matters.

What the person sees

Your export contains every entry, every correction and who made it, in a documented open format.

Tested annually by us rather than asserted, because an export path nobody has used is an export path nobody knows works.

Notice periods

Read them at signature. Automatic renewal with a long notice window is common, and organisations discover it six weeks after the window closed.

Put the notice date in a calendar with a reminder a month before, at the same time as signing.

Leaving well

Tell them why. A supplier told plainly that the entry experience was too slow, or that a promised integration never arrived, is more useful to the next customer than one told nothing, and occasionally the conversation produces a fix that changes the decision.

The export nobody has tested

Most organisations have never run a full export. It is offered, it appears in the contract, and whether it produces something usable is unknown until the moment it matters.

Run one in the first month, open it, and check it contains what you would need. If it does not, that is a conversation to have while you are a new customer.

Migration in reverse

Everything in the entry on migration applies again, with less cooperation. Category mapping, verification by totals, a cut-over at a period boundary, and keeping the old system available.

Budget the same effort. Organisations plan the arrival and improvise the departure.

Telling your people

A change of system is a change to their day. The rollout practices from the first part of this blog apply in full, and they are frequently skipped for a replacement on the reasoning that everybody already records time.

What a good supplier does

Provides the export without friction, confirms deletion, and asks why. Suppliers behave differently at this moment than at any other, and it is worth asking a reference about it before signing.

Termination for the supplier's reasons

Suppliers are acquired, change direction, or withdraw a product. The exit questions apply with less notice and no goodwill, which is the strongest argument for having answered them at procurement.

An annual verified export means this scenario costs you a quarter of inconvenience rather than a year of records.

The transition period

Running two systems while moving is unavoidable and should be short. Set a date on which the old one becomes read-only and hold it, because a system that remains writable is a system some people keep using.

What to record about the exit

What was exported, when, verified by whom, where it is stored, and the supplier's written confirmation of deletion.

Five facts on one page. In three years somebody will ask where the 2026 records are, and this page is the answer.

A closing thought

Exit terms are cheap to negotiate and expensive to need. Raise them in the first commercial conversation, when a supplier is most willing and least surprised.

Where to start

Run a full export this month, whoever your supplier is and whatever your intentions. Open it. That single action tells you more about your position than the contract does.

One line to carry

Ask the exit questions while you are still a prospect, and export a verified copy every year whether or not you intend to leave.

A note on tone

Exits are more cooperative than expected when handled plainly. Most suppliers behave well; the ones that do not are the reason for the contract terms, and the terms are cheap insurance against a minority.

Also in choosing and running the software