When you move house, everything goes into cardboard boxes. The first few days are fine — you labelled most of them, you roughly remember what went where, and it feels organised because you did it yourself. A week in, you are still sleeping next to a stack of boxes. The one labelled "kitchen essentials" has turned out to contain three phone chargers, a travel adaptor, and a single wooden spoon. "Miscellaneous" is doing a lot of heavy lifting. Finding anything requires opening four boxes and hoping.

After a month, nobody has time to unpack properly. The boxes have been repacked once already. Some have no label at all. Some have the wrong label. You can still find most things if you look hard enough and you were the one who packed — but the person who moved in six months later, or the new flatmate who joined the household? They are just guessing.

That is what an Excel candidate database looks like after three years of use at any agency with more than two recruiters.

I have seen this close-up more times than I care to count. The original spreadsheet was built by someone methodical. Columns were sensible. Colour coding made sense to the person who invented it. Then that person left. Someone else added a tab. Someone else changed the column logic without telling anyone. A consultant fixed it by creating a separate sheet, which nobody else opened. The master file has 47 versions in the shared drive, the most recent of which is called "FINAL_v3_Janis_edited_ACTUAL_USE_THIS_ONE.xlsx".

Every recruiter reading this just felt something in their chest.

The Real Cost of the Moving Box

The problem is not that Excel is a bad tool. Excel is a brilliant tool — for analysis, for financial modelling, for things that are fundamentally flat and tabular and do not need to be searched across multiple axes simultaneously. It is one of the most useful pieces of software ever built. Using it as a candidate database is like using a kitchen knife as a screwdriver. It works, a bit, for a while, until the handle snaps.

A recruitment agency's candidate database has to do things Excel structurally cannot do well. You need to search by availability, location, language, sector experience, notice period, and salary expectation — simultaneously, in seconds, while a client is on the phone. You need to see that this candidate was placed in 2023, left that role in 2024, and is now back in market. You need to know that a colleague already spoke to them this month without having to go and ask the colleague. You need the record to update when the candidate's situation changes without creating a new row that contradicts the old one.

None of that is what Excel was designed to handle. The result is that agencies working from spreadsheets effectively run blind on a large portion of their own database. The candidates are in there — but finding the right one at the right moment requires the institutional memory of the person who built the system, which is exactly the kind of knowledge that walks out the door when someone hands in their notice.

The hidden cost is not the time spent searching (though that adds up). The real cost is the placements you do not make because you did not surface the right candidate when the role came in. You went to the market, spent money on LinkedIn or job boards, sourced fresh, and filled the role — not knowing you had someone sitting in row 847 of tab 3 who would have been ideal. That is money and margin that evaporated silently.

What Specifically Goes Wrong (And When)

There are three moments where the moving-box database fails hardest. If any of these sounds familiar, the problem is structural, not fixable with better spreadsheet discipline.

The new hire moment. Someone joins your team. They get a login to the shared drive. You point them at the master file. They spend the first two weeks asking everyone where things are, partially learning the system, and then beginning to work in their own way — which differs from the existing system in ways nobody formally agrees to reconcile. Within six months, there are two parallel data practices running in the same agency, and nobody is quite sure which version of a candidate's status is correct.

The fast brief moment. A client calls with an urgent requirement. The person closest to their phone starts searching. Because search in a spreadsheet is essentially a text match across one or two columns, they may not find the candidate who fits if that candidate's entry was recorded under slightly different terminology by a different colleague two years ago. "Finance Director" and "CFO" and "Head of Finance" are three separate search terms. The candidate who applied describing himself as "Financial Controller seeking FD step-up" gets missed entirely. Off they go to LinkedIn to source fresh, paying €0.80 per InMail on a person who is already in the database.

The compliance moment. GDPR requires you to be able to demonstrate, on request, what data you hold on any individual and when you obtained consent to hold it. It also requires you to delete data when the legitimate interest for holding it has expired. In a properly structured candidate database, this is manageable. In a spreadsheet with seven tabs and three archived versions in the same folder, this is a time-consuming exercise that most agencies quietly dread. The right answer to "where is all your candidate data?" should not be "mostly here, but also maybe in that other file, and possibly in some email threads."

On the topic of candidate capture and data quality more broadly — read our post on why AI interview notes transform the quality of candidate data your team actually collects. The data problem starts before it reaches the spreadsheet.

"We Have 6,000 Candidates in There. Moving Everything Is Impossible."

This is the most common objection, and it is worth taking seriously — because it is not entirely wrong. Migration can be painful if done badly. The anxiety is real and justified by enough war stories of agencies who paid a consultant, spent three months on data cleaning, and ended up with a shiny new ATS that nobody trusted because the migration was messy.

But the logic of "migration is too hard, therefore we will stay on Excel" leads to an uncomfortable conclusion: your database gets larger and more tangled every month you wait. The moving boxes pile up. Next year the migration will be harder, not easier.

The other thing that has changed is the tools. Modern ATS platforms — including Yena — have AI-powered import that does the heavy lifting of mapping your spreadsheet. You upload the Excel file. The system reads the columns, infers what each one represents (candidate name, current title, location, notes, status, date last contacted), suggests a mapping, and imports the data. It is not perfect — no automated migration is — but it gets you 80–90% of the way there in minutes rather than weeks. The remaining cleanup happens organically as recruiters use the system: they open a record, see something outdated, update it. Within three months, the database you were afraid to touch has been refreshed by normal daily use.

Yena's free AI CV parser is a good demonstration of what this kind of structured extraction looks like before you commit to anything. Upload a CV, see how it pulls structured data. That same underlying logic powers the spreadsheet import.

What the Database Actually Needs to Do

Let me be concrete about the functional requirements a recruitment agency database has in 2026. Not nice-to-haves — actual operational requirements that translate directly into margin.

Multi-axis search in seconds. You should be able to search "senior finance professional, fluent German, available in less than 30 days, previously placed in manufacturing sector, salary expectation under €110k" and get a ranked shortlist. Not filtered rows — a ranked shortlist, with the most relevant matches first. This requires semantic matching across multiple fields simultaneously, which is an AI and database architecture problem, not a formula problem.

Activity history per candidate. Every call logged, every email sent, every placement, every rejection, every feedback note from a previous interview. When a recruiter opens a candidate profile, they should be able to see the full relationship history in two minutes without asking a colleague. This becomes especially important as teams grow and candidate relationships span multiple recruiters over time.

Status and availability tracking. Candidate records should reflect current reality: employed and passively looking, actively seeking, in a process with a client, placed and off limits for a defined period. In Excel, status updates require discipline — the right person has to update the right cell consistently. In a proper ATS, status changes flow from activity: when you log "placed at Müller GmbH, start date 1 March," the system updates the candidate's status automatically.

Skill tagging that survives different terminology. This is directly connected to the broader shift in how roles are being defined. As we covered in our skills-based hiring playbook, employers are increasingly specifying competencies rather than credentials. Your database needs to match on those competencies — which means tagging needs to be structured and searchable, not free-text notes in a column.

Client-facing shortlist capability. Increasingly, the expectation from clients — particularly in executive and professional search — is not a list of names in an email but a structured, reviewed shortlist with candidate summaries, availability, and context. This is something a spreadsheet cannot produce. The client portal that Yena provides lets your agency present candidates in a way that positions you as a consulting partner, not just a CV forwarder. Clients approve, decline, and give feedback directly. That feedback feeds back into the matching logic.

The Collaboration Problem Nobody Talks About

Single-recruiter agencies do not feel the Excel pain as acutely. One person built it, one person maintains it, one person searches it. The institutional knowledge problem is manageable because the institution is one person.

The moment you add a second or third recruiter, you are in a different situation. Now the database is a shared object that multiple people are updating, searching, and interpreting differently. Excel handles this badly by design — it was built for individual use, with collaboration bolted on later. The canonical problem is two people editing the same record at the same time, producing a merge conflict that writes the wrong data silently. But the more common problem is subtler: different people have different mental models of what the same field means, and over time those differences accumulate into a database that nobody fully trusts.

"I always note salary as the base," says one recruiter. "I include OTE," says another. Now half your salary column is base and half is total comp and you have no way of knowing which is which without opening each individual CV. Good luck running any compensation analysis, or quickly telling a client whether you have options within their budget.

A proper candidate database enforces structured fields, not free text. Salary is a number in a defined currency with a field for "base/OTE/total comp". Notice period is a dropdown. Location is a geocoded field, not a free-text entry where one recruiter writes "Munich" and another writes "München" and both are different from "Bavaria" and "DE-Munich" and "South Germany". The discipline of structure is not a constraint — it is what makes the data actually useful at scale.

The Candidate Experience Consequence

There is a candidate-side cost that often goes unmentioned in these conversations, but it matters both commercially and reputationally.

A recruiter working from an Excel database has to re-ask candidates for basic information every time they re-engage them. "Can you remind me of your current salary expectations?" "Where are you based again?" "Are you still with the same employer?" Every one of those questions communicates, in a small way, that the agency does not remember them. Candidates notice. The best ones — who have choices about which agencies they engage with — gravitate towards the agencies that make them feel known.

The complement to this is speed. When you surface a candidate's full profile instantly and can see that you last spoke in October, what was discussed, and what they said about their current situation, the quality of the opening call is completely different. You are not establishing context — you are continuing a relationship. As we wrote in our piece on how slow response cycles leak revenue, speed of personalised engagement is one of the sharpest competitive advantages any agency has. It starts in the database.

What the First Week Looks Like in Practice

Agencies that have made this transition consistently report the same pattern: the fear of migration was greater than the migration itself. Here is a practical sequence that works.

Day one: export and audit. Export your Excel data to CSV. Open it in a spreadsheet and count: how many records do you actually have? How many are active (contacted in the last 12 months)? How many are genuinely useful (have contact details and at least a current role)? For most agencies, the working database is 20–30% of the total file. The rest is historical noise that you can either migrate as-is or archive.

Days two to three: import. Upload your CSV to Yena. The AI reads the columns and suggests a field mapping. Review the suggestions, adjust anything that is obviously wrong, run the import. Do not try to clean the data first — import it messy. You will clean it as you use it. Perfectionism at import stage is the most common reason migrations stall.

Days four to five: test against real work. Take a live brief you are currently working on. Run the search in the new system. See what comes up. Where the results are wrong or incomplete, note the pattern — usually it reveals a tagging or field mapping issue you can fix quickly. The goal is not a perfect system on day five. The goal is a system you trust enough to use as your primary lookup when a client calls.

Week two onward: capture everything new in the ATS, nothing in Excel. The old spreadsheet stays open in read-only mode for two to four weeks as a reference. Every new candidate, every new call, every new placement goes into the ATS. After a month, you will rarely need to go back to the old file.

The Question of Cost

I spent years paying what I later discovered was a painful amount for an ATS — €33,000 per year for a system built for eight people. When I built Yena, one of the hard requirements was that the economics had to make sense for agencies that are not swimming in margin. A solo recruiter operating a boutique practice should be able to run a professional ATS without dedicating a chunk of their monthly revenue to software they resent.

At €69 per month for a full-featured platform — ATS, CRM, AI matching, client portal, LinkedIn extension, campaign management — the maths is fairly straightforward. If the system surfaces one placement you would otherwise have missed, it has paid for itself for a year. If it saves each recruiter two hours a week in search time, it has paid for itself in recovered productivity inside the first month. The spreadsheet is not actually free. It just bills you in different currency.

You can start on a 10-day free trial with all features live — no credit card required. The import process is built in from day one, so you can bring your existing data with you rather than starting from scratch.

Unpacking the Boxes

Moving house with cardboard boxes is fine as a temporary state. The problem is when "temporary" stretches into years, the boxes multiply, and the labelling degrades to the point where finding anything requires either luck or the specific knowledge of the one person who packed the relevant box.

Most recruitment agencies are not fully aware of how much candidate value is sitting inaccessible in their Excel files. They do not see the placements they did not make because the search failed. They do not see the sourcing spend on candidates who were already in the database. They do not see the candidate relationships that cooled because re-engagement was too laborious to prioritise.

The question is not whether to unpack. It is how long you plan to keep tripping over the boxes first.

If you are considering the shift — or if you have already decided but the migration feels overwhelming — the practical starting point is one click and one CSV export. Everything after that is simpler than you expect.