How to Migrate PTO Data Without Losing the Balances

Migrations fail in a predictable way. Not with an error message — with a balance that is quietly two days wrong, discovered nine months later by the person it belongs to.

The technical part is easy. Every tool worth using will read a spreadsheet. The part that goes wrong is everything around it: which numbers you carry over, what happens to time already booked, and whether anybody checked the figures before they became the new source of truth.

Step 1: Reconcile before you move anything

This is the step people skip, and it is the one that matters.

Do not migrate the balance your spreadsheet currently shows. Recalculate it, for every person, from first principles:

Start with the rule. Annual allowance, accrual method, start date, and any carryover brought in.

Add what they earned. Periods elapsed multiplied by the per-period rate — or hours worked divided by the ratio, if you accrue per hour. The PTO accrual calculator will do this quickly.

Apply the cap. On the running total, not the period. A cap applied per period limits how fast a balance grows but never stops it, and this is the single most common source of drift in a hand-built tracker.

Subtract what they took. From the record of days actually taken, not from a running balance someone has been editing.

Where your recalculated figure and the spreadsheet disagree, the spreadsheet is usually wrong — but not always, and the difference is worth understanding before you carry it forward.

Step 2: Decide what actually moves

You do not need everything.

Full history is the item people agonise over and rarely need. Keeping the old spreadsheet read-only as a historical record is faster, costs nothing, and answers the same questions.

Step 3: The approved-but-not-taken problem

This is the item most commonly dropped, and it causes the most visible failure.

Someone was approved in March for two weeks in September. If that booking does not make it into the new system, the calendar shows them available, someone else books the same period, and the new tool has produced exactly the clash it was bought to prevent — in its first month.

Before go-live, list every approved booking with a start date in the future and enter them. It is usually a handful of rows and it is the difference between the new system being trusted and being second-guessed.

Step 4: Pick a clean cut-over date

If you are switching mid-period, decide explicitly whether the old system or the new one accrues for that period. Both is a double credit; neither is a silent loss. Write the decision down — it will be asked about.

Step 5: Import rather than retype

Retyping a roster is slow and introduces errors precisely where they are most expensive.

Most tools read a spreadsheet with a header row containing a name and an email. Importing an existing sheet carries departments, allowances and carryover across, shows a preview of everyone who would be invited, and reports bad rows individually rather than rejecting the file.

Two practical notes:

• Delete the sample rows if your file came from a downloaded template. They usually use @example.com addresses that can never receive mail, and importing them sends invitations that bounce.
• Check the preview before confirming. Nothing should send until you have read the list. If a tool imports without showing you first, that is worth knowing before you use it for anything else.

Step 6: Do not run both systems in parallel

The instinct is to keep the spreadsheet updated for a month "just in case". It is the wrong instinct.

Two live systems means two answers to the same question, and the moment they disagree — which is immediate — nobody knows which to believe. Worse, updating both is a chore that gets dropped in week two, silently, leaving a stale file that still looks authoritative.

Cut over properly. Keep the old file read-only, clearly marked, and answer historical questions from it.

Step 7: Tell people what changed

The migration is not finished when the data is in. Send one short message covering:

1. Where to check their balance now
2. How to request time off from today
3. What their opening balance is, and that it was reconciled
4. Where the old records live if they want to check something

Skipping this produces the most avoidable outcome of all: a correctly migrated system nobody uses, while requests keep arriving by chat.

A realistic timeline

For a team under thirty people:

• Reconcile balances — half a day
• Confirm figures with staff — two or three days of waiting
• Import and enter future bookings — under an hour
• Announce and cut over — one message

The waiting is the long part, and it is the part worth not rushing. Everything else is an afternoon.

When to switch from a spreadsheet covers whether you should be doing this at all, and why spreadsheets break for PTO covers the failure modes you are migrating away from.