Migrate your data to Kula
Last updated: September 3, 2026
Kula runs your migration for you. You give us access to your current system or a data export, we bring the data across, and you check it before you go live. This guide covers the whole journey and links out to the detail at each step.
Who can do this: Super Admin, Admin — working with your Kula implementation contact
Where to find it: there is no migration screen in Kula. The work is coordinated with your implementation contact, and the results appear in your account as ordinary jobs and candidates.
The two kinds of migration
Which one you get depends on the system you are leaving, not on a choice you make.
Connected migration | File migration | |
|---|---|---|
How the data reaches Kula | You give us an API key and Kula pulls the data directly | You send us an export from your current system |
Systems | Ashby, Freshteam, Greenhouse, Lever, Manatal, Recruitee, Recruiterflow, Trakstar, UKG Pro, UKG Pro (HCM), Workable | JazzHR, BreezyHR, Gem, Pinpoint, Rippling, Skillate, Personio |
What you prepare | An API key | A full data export |
Resumes and attachments | Included | Depends on your export — confirm with your contact |
Repeat runs before go-live | Yes, an incremental sync | Yes, as additional batches |
If your current system is not on either list, tell your implementation contact anyway. Several migrations have been done from systems that were not supported when the customer asked.
Before you start
Three decisions shape the whole migration. Settle them early.
When does your current contract end? This is the hard deadline, and it is the first thing we ask for. Once your old system is switched off, the data cannot be pulled again. Give us the date even if it is months away.
How much history do you want? You do not have to bring everything. Many teams bring active jobs and their candidates, and leave years of archived data behind. Bringing less makes the migration faster and your new account cleaner.
Who is checking the result? Migration finishes with your team confirming the data looks right. Name that person now — it is usually whoever knows the old system best, not whoever is most senior.
How a migration runs
Send your details to your implementation contact. Your Kula account, the system you are leaving, its contract end date, and how much history you want.
Give us access. An API key for a connected migration, or an export for a file migration.
Kula runs the first pass. We bring across your jobs, candidates and everything else your source supports, in dependency order — offices and departments first, then jobs, then candidates and their applications, then attachments.
You check the result. We hand the account back and you confirm the data is right. This step is yours, and it is the one that catches problems while they are still cheap to fix.
Kula runs an incremental sync near go-live. Everything that happened in your old system since the first pass is brought across, so you go live with current data.
That last step is why the first pass does not have to be perfectly timed. You can migrate weeks ahead, work in both systems, and catch up at the end.
Large migrations run in phases
If you have a lot of jobs, we bring them across in phases by job status rather than all at once, and we start with the jobs that matter.
The usual order is published jobs first, then internally published, then jobs no longer accepting candidates, then drafts, then archived jobs.
This means your live hiring is available in Kula early, while the archive is still arriving. If you only care about live roles, say so — the later phases can be dropped.
Good to know
There is no self-serve migration. You cannot start, re-run or roll back a migration from inside Kula. Every migration is run by Kula's team.
Assessments never migrate. No source brings assessment records across. If you need assessment history, keep a copy outside Kula before your contract ends.
Duplicate candidates are matched on email address. Someone who appears twice in your old system under two different email addresses arrives in Kula as two candidates.
Keep both systems running until you have validated. Do not let your old contract lapse before your team has confirmed the data.
FAQ
How long does a migration take? It depends on the size of your data and which system you are leaving, so ask your implementation contact for an estimate against your account. What is in your control is the deadline: give us your current contract's end date up front and we plan backwards from it.
Our contract with our old ATS ends soon. Is it too late? Tell your implementation contact today with the exact end date. Once the old system is switched off, an API migration is no longer possible and your only route is whatever export you managed to take first. For more, see Prepare a connected migration.
Do we have to bring all our old candidates across? No, and most teams do not. You can migrate only active jobs and their candidates, or set a cut-off date. Less data means a faster migration and a cleaner account.
We've already started using Kula. Can we still migrate our old data in? Yes. Migrations are regularly run into accounts that are already live, including in batches over several weeks. Tell your implementation contact what still needs to come across.
Will our resumes come across? From a connected migration, yes. From a file migration it depends on what your export contains — confirm with your implementation contact before you assume either way. For more, see What data comes across in a migration.
Something looks wrong in our migrated data. What now? Raise it with your implementation contact while the migration is still open rather than fixing records by hand. Corrections are usually cheaper to make in the migration than in the account.
Need help? If you have questions or need assistance, reach out to us at support@kula.ai or use the in-app chat.