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 tests the connection the moment they are entered and keeps the result, so anyone on the Lovelio side can see the server, port, protocol, username and folder and whether the last test passed, and can test again at any time. JobAdder backups are always collected over FTPS on port 990, so Lovelio stores them that way whatever was typed, and if older saved details say otherwise both consoles show a red warning and the next fetch launch or connection test corrects them with the same password, so nothing is re-entered. 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, from the number of consultants in your export. 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.

AI processing during migration

Migration accounts have unrestricted AI processing. CV parsing, profiles and enrichment do not stop at a daily spending limit or wait for a daily approval. Lovelio records the actual cost throughout the migration. Normal account spending rules apply when the account goes live.

The next stage starts automatically. When the Lovelio team restarts a single phase, it uses the saved approved tenant and plan settings. There is no need to enter the company ID or load confirmation flags again. Load, attachments, bulk enrichment, AI result collection and search indexing share one processing slot per region to protect the live database. If another import holds that slot, the console shows Queued. It starts when capacity becomes available; you do not need to launch it. Waiting imports share a fair queue, so newer work cannot repeatedly take the next slot. A running stage finishes its turn before another import starts.

Client enrichment and its related migration follow-ups share a separate allowance of 20 active background steps across regions. More work stays queued and starts automatically. This controls processing capacity, not spending or the number of imported records. Other systems sharing the background account and older queued work can still cause delays.

Before any phase starts, Lovelio checks what that phase needs: the files the previous phase produced, the tenant when the phase writes to it, the background job receiver for the region, the worker's AI provider keys, the worker's keys for reading client websites and CVs, and free capacity in the region. The worker takes those keys from Lovelio's own settings by itself, so attachments, enrich and batch wait a few minutes after a key changes while the worker restarts with it. A client whose website read failed on Lovelio's side (a missing key, no credits, a rate limit) is never listed as the client's problem: it is tried again automatically, and Lovelio is alerted if it keeps failing. If a check fails, no worker starts and the console shows the reason in plain words on the run, for example "Enrich needs the migration's tenant and it has none yet". A temporary cause, such as the receiver not answering, is checked again automatically every few minutes and the phase starts when it passes; it never counts as a failed attempt. A cause that needs a person, such as a missing file or tenant, waits until it is fixed and the phase is re-launched.

Temporary provider and database outages wait and retry automatically. A record or file that fails for a temporary reason, such as a timeout or a dropped connection, is retried within the same stage before it reports, and the report says how many recovered. Anything still failing for a temporary reason when the load ends is replayed by the AI result collection stage, which keeps trying until it lands. An interrupted worker resumes from durable progress.

The AI result collection stage is one long-running worker. It sends the AI work, waits for the provider to finish it, collects the answers and applies them, and it keeps going in the same worker until nothing is owed. Waiting on the provider is what this stage does, so the console shows the last pass on the run (what it sent, collected and applied, and how much is still at the provider) rather than an attempt count, along with when it expects to finish, measured from how fast the pending work is falling. If that projection passes 20 hours from the start of the stage, a system alert goes out once so somebody can look while there is still time. A dropped connection, a timeout or a provider error is tried again later, up to twelve times, and is never listed as a record that needs a person. It stops early only when a setting or credential has failed and nothing else is moving, and it says which. If the AI provider turns every request away because the account has reached its usage cap or run out of credit, the stage parks straight away with the provider's own sentence on the run (including the date access returns), the work stays queued rather than being listed as needing a person, and the run retries on its own until the cap lifts.

Records that need a person never hold the migration up. An unreadable CV, an application whose job was not exported, a client profile that could not be built: each is listed in the report with its reason, and the migration reads complete with "N records need a person". Every one of them, including anything set aside so the import could finish, is also listed one per line in "Records for a person" under More, then Reports, on the migration console: the record, its name, its Lovelio ID or old system ID, the step and the reason. It downloads as a spreadsheet file to work through at any time. The report is the place to read about them; withholding the report over them would hide the list. Only a failed setting or credential blocks, because no list fixes that. If the final report finds required work still owed, the AI result collection stage runs again by itself and the report follows; nothing needs relaunching by hand. If part of the work fails on a fault in Lovelio itself, the migration pauses, the team is told, and it runs again by itself once the fix is live. That collection stage waits on the AI provider without holding up other agencies migrating into the same region.

If the console says Waiting for the database upgrade, the worker is waiting for required database changes before writing records. It retries automatically. Scheduled backups and database upgrades queue behind each other so an upgrade does not hold up live database requests while a backup finishes.

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. Contract and temp placements come across with their end date and their charge and pay rates (hourly, daily or weekly), so contractors still working show on the Contractors page from day one. Records keep their original ids in a mapping table, so re-runs and delta syncs recognise every record they have seen before.

Only records your team has actually worked with come across. The window is five years by default and applies to everything: candidates, client companies, client contacts and jobs. A record counts as worked if it was created in that time, has a note from your team, or had pipeline activity. A company you placed with, and anything else a kept placement or application depends on, always comes across whatever its age. Companies and contacts nobody has spoken to in the window stay behind in your old system.

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.

Going live

When the import is complete, the migration console says "Import complete. Ready to go live." with a Go live button, on the migration's own page and in the list. It opens that account's Data import section in your region's admin. Go live waits until every CV is read: if any are still being read, it says how many and refuses, so a client never starts on a database Lovelio is still reading. A CV Lovelio could not read at all does not hold it up. Going live switches email back on. If a card is already on, the free days restart that day; if not, they start when an admin signs in and adds one. The console then says Live. The migration page shows only where it is up to and the next step; the steps, scorecard, links, rules, runs and single-phase tools sit behind More.

Recovering failed imports (admin)

Open Migration Magic, select the migration, open More, and select the load phase in the single-phase tools. Enter --retry-load-failures in Extra args. The saved plan supplies the tenant. This retries only unresolved load exceptions that the approved selection still keeps. It leaves other records, enrichment, and the full-load checkpoint alone. It stops after recovery even though ordinary load runs continue through the pipeline. A separate recovery receipt reports what it attempted and what remains. An empty exceptions list does not start a full import.

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.

Emails while a migration runs

A migration that goes well sends one email: when it is complete, to the person running it and Lovelio. It says how long it took, the AI spend, and how many records (if any) need a person, which the report lists. No email goes as each step finishes; the migration console shows progress live.

The morning digest goes at 06:00 UTC only on a day something in a live migration needs a person. It says which phase it is in and since when, which phases finished in the last day and how long they took, anything that was retried and why in plain words, anything waiting and what it is waiting for, and the measured AI spend so far against the approved quote. The last section is called "What needs you" and lists only the decisions a person has to make: approve the quote, fix credentials, look at a run that may be stuck. Each item links to the migration console. A run that parks on a problem still emails straight away.