Switching from BambooHR: What to Export, What to Check, and How to Sequence the Cutover

Most teams who decide to move off an HR platform stall at the same point. Not the decision — that part is usually settled weeks earlier. They stall at the moment someone asks "so what do we actually do about the data?", nobody has a confident answer, and the project quietly slides another quarter.

This guide is the answer for teams leaving BambooHR. It is deliberately unglamorous: what to export, what will be wrong in the export, what order to do things in, and where the genuine risks are. Most of it applies to any HR migration, but the specifics here are BambooHR's.

Start by Deciding What You Are Actually Migrating

The instinct is to move everything. Resist it. A migration that tries to bring across five years of every record type takes three months and usually gets abandoned. A migration that brings across the three things people use daily takes an afternoon.

For a leave and time-off migration, that is:

1. The employee directory — names, work emails, job titles, departments, start dates, and reporting lines.
2. Leave balances — where everyone currently stands, per leave type.
3. Leave history — past and upcoming approved time off.

Everything else — documents, performance reviews, benefits enrolment, historical payroll — is a separate decision, and for most teams the honest answer is that it stays in the old system for its retention period and is archived rather than migrated. Deciding that explicitly is much better than discovering it halfway through.

The one thing worth arguing about is how much history. Two years of leave history is usually plenty: it covers the current and previous leave year, which is what people actually reference. Ten years is a data-cleaning project wearing a migration costume.

Getting the Data Out of BambooHR

BambooHR gives you two routes. Which one you use changes the shape of the work considerably.

The file export

The standard path is People → Employee List → Export, choosing CSV and selecting the fields you want. It is straightforward and it is what most teams use.

A BambooHR employee export typically carries columns along these lines:

Employee #, First Name, Last Name, Preferred Name, Email, Job Title, Department, Division, Location, Reports To, Hire Date, Employment Status, Mobile Phone, Work Phone, Work Ext, Home Email, Date of Birth, Gender, Marital Status, Address Line 1, Address Line 2, City, State/Province, ZIP Code, Country

Time off comes from a separate export, with its own shape — typically Employee, Type, Start, End, Amount, Status, Note.

Two details in there will bite you if you are mapping by hand. Dates come out in US format (MM/DD/YYYY), which means anything before the 13th of a month is ambiguous to a parser expecting DD/MM/YYYY and will silently import as the wrong date rather than failing. And Reports To is a name, not an email, so linking managers requires matching on a display name that may not be unique in a large directory.

The API

BambooHR also has an API, authenticated with an API key plus your account subdomain. If your destination system can talk to it directly, this is the better route: no export step, no file to keep track of, no stale snapshot, and you can pull again later rather than redoing the whole exercise if you find a problem. BookYourPTO connects to BambooHR this way — you can see how that works on the switch from BambooHR page.

Whichever route you take, do the export twice: once early as a dry run so you can see the real shape of your data, and once on cutover day so what you load is current.

Clean the Directory Before You Import, Not After

This is the step that determines whether the migration is pleasant. Open the dry-run export in a spreadsheet and work through this list. It is worth an hour.

Duplicate email addresses. Sort by email and look. Duplicates usually mean someone was created twice, or a contractor was converted to an employee without merging. Decide which record wins now, because most import tools will either skip the second one or create two people, and neither is what you want discovered later.

Missing emails. Anyone without a work email cannot be matched by leave history and cannot be invited to log in. Shift workers and site staff are the usual gap. Either source the addresses or accept that those people are entered by hand afterwards.

Terminated employees still in the export. Filter them out unless you specifically want them, and be deliberate — importing leavers into a per-user-priced system is an expensive way to keep an archive.

Department names that are nearly the same. "Engineering", "engineering", and "Eng" will create three departments. Normalise them in the spreadsheet.

Managers who are not in the file. If a Reports To value names someone who was filtered out or never existed as an employee record, the reporting line will not resolve. Check the manager column against the email column before you load.

Leave types. List the distinct values in the Type column of your time-off export. That list is what your new system needs to have configured, and it is almost always shorter and messier than people expect — a handful of real types plus two or three that were created once and never used again.

Sequence the Cutover

Order matters, because the records depend on each other.

Employees first, then departments, then leave history. Leave history references an employee by email, so it has nothing to attach to if the people are not there yet. Departments need to exist before employees can be assigned to them — though most import tools will create a missing department automatically from the employee row, which is usually what you want. Manager relationships resolve last, after every employee record exists, because you cannot point at a record that has not been created.

Pick a quiet week. Not month-end, not the week before a holiday period, and not while someone critical is away. The migration itself is short; the questions afterwards are not.

Freeze bookings for the changeover. A day is normally enough. Tell people that requests made on Tuesday will need re-entering, and almost nobody will make one.

Run both systems read-only in parallel for one leave cycle. Do not keep double-entering — that is how data diverges — but leave BambooHR accessible for a month so you can check anything that looks wrong against the source. Then export a final archive and decommission.

Verify Before You Trust It

The temptation after a successful-looking import is to declare victory. Spend twenty minutes on these instead.

Count the rows. Employees imported versus employees in the file, minus whatever you deliberately excluded. If the numbers do not reconcile exactly, find out why before doing anything else.

Check three balances by hand. Pick a long-tenured employee, a recent joiner, and someone who has taken an unusual pattern of leave. Compare their balance in the new system against BambooHR. Getting all three right is strong evidence the arithmetic is correct; getting the recent joiner wrong usually means pro-rating was not applied.

Check a date near the start of a month. This is the US-date-format trap. Find a leave request that started on, say, the 3rd of a month and confirm it did not import as the 3rd of a different month.

Spot-check the org chart. Open the reporting tree and look for anyone reporting to the wrong person or to nobody. Name-matched manager fields are the most common source of quiet errors.

Confirm nobody was emailed. A good import creates employee records without notifying anyone, so you control when people are invited. Check this before you import 200 people, not after.

What You Do Not Have to Migrate

Worth saying plainly, because it removes a lot of anxiety: you do not need to migrate anything you can archive.

Old performance reviews, historical documents, benefits records from three plan years ago — export them, store them somewhere durable with an access policy, and note the retention period. That is a filing decision, not a migration, and treating it as one takes weeks off the project.

The things that must move are the things people touch weekly. Everything else can be looked up in an archive on the rare occasion it is needed.

The Realistic Timeline

For a team of fifty, a leave-and-directory migration done properly is roughly:

• Half a day — dry-run export, clean the directory, list the leave types.
• An hour — configure leave types and policies in the new system to match.
• An hour — the actual import, plus verification.
• A week — people asking where things are, and one or two records you fix by hand.

The half-day of cleaning is the part everyone wants to skip and the part that determines how the other three go. If you take one thing from this guide, take that.

Moving from something other than BambooHR? The same sequence applies — the export mechanics change, the cleaning and the ordering do not. Our switch from pages cover the export steps for the platforms we see most often.