Switching to Lovelio: migrating your data

Signed in? Ask Lovelio this question inside the app - it answers from this same page.

Lovelio runs your migration for you. You do not import spreadsheets or map fields yourself - the Lovelio team takes a full backup of your current system and loads it through the same quality checks every Lovelio record goes through.

How it works

1. You ask your current ATS provider for a full data export (for JobAdder this is a database backup plus attachment archives, delivered on an SFTP server - they email you the login details).
2. You hand those SFTP details to the Lovelio team. Lovelio pulls the files directly from the provider into secure storage in YOUR region - US, EU, or Australia/New Zealand. EU data never leaves the EU. The SFTP password is held in a secrets vault, never in Lovelio's database, and is deleted after go-live.
3. Lovelio reads the whole export and sends you a data assessment as a web page link that opens straight from the email, nothing to sign into. It shows what your database holds, how complete the records are, and what comes across, including how the candidate count changes if the import window moves. It ends with the Lovelio plan that fits: the size comes from the number of consultants in your export, and Standard or AI Ultra from what a year of your work (new candidates, applications and jobs) would use in AI credits, with room to spare. It is a starting point, not a bill: you pick your own plan at sign-up and can move at any time.
4. Lovelio runs a TEST import first: your full history loads into a test workspace so you can check candidates, clients, jobs and placements look right before anything is final.
5. For go-live, your provider supplies a fresh backup and the pipeline re-runs against it. The loader is idempotent - records already imported update in place instead of duplicating - so the gap between the test and go-live closes cleanly.

Before the go-live run touches anything, Lovelio reads a plan of exactly what it would do: how many records are new, how many changed, how many are identical to the test import, and which fields moved on the ones that did. A record that did not change is left alone completely, right down to the AI work. Your CVs are read once and your candidates' search profiles are built once, at the test import, and the go-live does not redo either.

Which CV a candidate ends up with

A candidate in an old system usually has several resumes on file, added over years. Lovelio makes the most recent one their CV - the one every search, shortlist and AI summary is built from - and files the rest on their Documents tab, so nothing is lost. If a newer resume arrives between your test import and go-live, it becomes the CV and Lovelio re-reads it.

A CV that someone on your team uploaded is never replaced by an import. If a consultant put a file on a candidate, that is the CV, and a migration leaves it alone.

CVs that cannot be read

Old books always contain some CVs nobody can read: a scan or a photograph with no text in the file, a password-protected PDF, a file saved with the wrong extension years ago. Lovelio reads every CV, and where the file has no text of its own it runs text recognition over the pages.

Some books also hold "CVs" that are really three lines of contact detail: a name, a location, and a job title with an employer after it. They are not resumes and they are not broken, so Lovelio reads them exactly as they are and fills in the current job title and employer, word for word. It never writes a summary or a work history the file does not contain. Where the shape is different, or the title or the employer is missing, the candidate is left alone rather than guessed at.

The ones that still cannot be read are counted on the migration console and listed by name at the top of your migration report, with the reason for each: scanned and unreadable, password-protected, or a file type nothing can open. That list is short and it is the one thing to check, because a candidate whose CV never parsed will not turn up in a search that should find them. Re-upload a readable copy and Lovelio parses it straight away and takes them off the list.

Candidate CVs are read inside Lovelio's own infrastructure, in your region. They are never sent to an outside document-parsing service.

Nothing is ever deleted

If a candidate, client or job is in your test import but missing from the go-live backup, Lovelio keeps it. It is listed in the plan as something to look at, and that is all that happens to it. Records go missing from an export for all sorts of reasons - somebody archived them, the export window moved, a filter changed - and none of those are a reason to destroy your data. Deleting anything is a decision you make in Lovelio afterwards, never something a migration does on your behalf.

What carries over

Candidates (with work history, resumes and contact details), client companies and their contacts, jobs, applications and their pipeline stages, placements, notes, and attachments. Records keep their original ids in a mapping table, so re-runs and delta syncs recognise every record they have seen before.

Custom fields become tags

Lovelio has no custom fields, by design - they are the reason legacy ATS setups rot. During migration, the fields your team genuinely used (folder names, flags, categories) are reviewed with you on a short call and land as tags on the record, which are searchable like everything else. Fields nobody used are dropped, and the migration report says exactly what went where.

Your old backup

The original backup files are archived for 6 months after go-live, then deleted. If you need something looked up from the old system in that window, ask - restoring from the archive takes minutes, not days.