The short answer
Moving compliance dates off a spreadsheet is mostly a data problem, not a software one. Export everything cleanly, check for duplicate or conflicting dates before they go anywhere near the new system, attach the actual certificate to each date rather than just the number, and set reminder lead times in weeks rather than days. Keep the old spreadsheet running alongside the new system for one full cycle before you trust it completely. Done properly, nothing gets lost in the move and you find out about any existing errors before they become a missed deadline, not after.
What moving off the spreadsheet involves
This isn't a like-for-like copy. A spreadsheet stores a date in a cell, with maybe a note about where the certificate lives, if it's noted at all. A proper system stores the property, the tenancy, the compliance requirement, the date, the evidence, and the reminder rule, all linked together. The migration is the work of turning one flat row of data into that fuller record, for every property and every clock you're tracking, which is exactly the point where errors already sitting in the spreadsheet tend to surface. For what those clocks actually are, gas safety, EICR, EPC, deposit protection and Right to Rent, see our landlord compliance checklist; this page assumes you already know what you're tracking and covers moving it safely.
Exporting dates and documents cleanly
Start with the spreadsheet itself, not the new system. Export it to a clean format (a straightforward CSV works for most systems) with one row per property per compliance item, rather than one row per property with several dates crammed into different columns. If certificates are stored as files on a computer or in email attachments rather than linked from the spreadsheet, gather them into one folder, named consistently by property and requirement, before the import rather than chasing them down afterwards. This sounds like extra work before the real migration starts, but it's considerably easier to do once, calmly, than to reconstruct later when a system's already half populated.
Catching duplicate and conflicting entries
Every spreadsheet that's been edited by more than one person, or over several years, has at least one conflicting entry: two different dates for the same property's gas safety check, a row that was copied for a new property but never updated, a certificate that was renewed and the old date never removed. These are easy to miss in a spreadsheet because nothing flags them, you only find out when two rows disagree and you're not sure which is current.
Before importing, sort by property and requirement type and look specifically for duplicates and date clashes. Where you find one, check the actual certificate rather than guessing which row is right. This is the single most valuable step in the whole migration, because it's the one point where you're deliberately looking for an error that might otherwise have sat undiscovered until a renewal was missed.
Attach the certificate, not just the date
A date on its own answers "when is this due." It doesn't answer "can I prove it was done," which is the question that actually matters if a tenant, a mortgage lender or an insurer ever asks. As each date goes into the new system, attach the certificate or evidence document to it directly, rather than leaving documents in a separate folder that someone has to go searching for later. This is the single biggest practical improvement over a spreadsheet: the evidence lives next to the date it relates to, not in a different place that depends on someone remembering where they put it.
Reminder lead times that actually work
Set reminder lead times in weeks, not days. A reminder that fires the day a gas safety certificate expires is almost useless, you need an engineer booked and the check carried out before that date, not starting the process on it. A few weeks' notice gives genuine time to book a contractor, especially for EICRs, where qualified electricians can have a longer lead time than gas engineers. Set a first reminder with real notice and a second, closer one as a backstop, rather than relying on a single alert that might get missed in a busy week.
Run both in parallel for a cycle
Don't delete or abandon the spreadsheet the moment the new system is populated. Keep it as a passive backup and check both against each other for at least one full renewal cycle, which for most of these dates means a few months at minimum. This catches any import errors while you've still got the original to compare against, and it means you're never relying on a system you haven't yet had the chance to trust. Once you've been through a cycle without a discrepancy, the spreadsheet can be archived rather than kept live.
What usually goes wrong
The most common mistake isn't a technical one, it's rushing the duplicate-checking step because the spreadsheet "looks fine." Nearly every spreadsheet that's grown past a handful of properties has at least one error hiding in it, and the migration is the best opportunity you'll get to find it before it causes a missed deadline. The second most common mistake is importing dates without the certificates, meaning the new system looks complete but the evidence is still scattered across old emails and files, which defeats much of the point of moving in the first place.
When to get help, and what we'd do
We'd usually handle this as a clean import of your existing spreadsheet data, a guide price from £300, which includes checking for duplicate or conflicting dates as part of the move rather than importing them as found. Alongside that, setting reminder lead times properly is usually scoped as part of a simple automated workflow, from £350, so the reminders are live from day one rather than configured as an afterthought. These are guide prices for a typical project; the fixed quote comes after a free 30-minute call. If you haven't yet decided which system to move into, our comparison of Reapit, Alto, Arthur or a one-off system covers that choice first.
This is the practical half of fixing a creaking compliance spreadsheet: choosing the right system matters, but the migration itself is where dates actually get lost or found, so it's worth doing properly rather than rushing to get it over with.
Related
- General guide: The business runs on a spreadsheet that's creaking
- Sector pillar: Property spreadsheet chaos
- Sibling page: Reapit, Alto, Arthur, or none of them?
- Guide: 7 signs your business has outgrown spreadsheets
Frequently asked questions
Is it risky to move compliance dates out of a spreadsheet?
Not if it's done in the right order: export cleanly, check for duplicates and conflicts, attach the certificates, then run the old spreadsheet alongside the new system for one full cycle before retiring it. Most of the risk comes from skipping the checking step, not from the move itself.
How do I find duplicate or conflicting dates before they cause a problem?
Sort the exported data by property and requirement type and look specifically for two different dates against the same item. Check the actual certificate rather than guessing which row is correct, since this is the point where an existing error is most likely to surface.
Should certificates be stored in the same system as the dates?
Yes, wherever possible. A date without the evidence attached only tells you when something's due, not whether you can prove it happened. Keeping the document next to the date removes the need to go searching for it later.
How far ahead should a gas safety or EICR reminder fire?
Several weeks, not days. That gives real time to book a contractor, which matters especially for EICRs, where qualified electricians can have longer lead times than gas engineers for a routine certificate renewal.
How long should I keep the old spreadsheet running after moving to a new system?
At least one full renewal cycle for your fastest-moving compliance item, typically a few months. This gives you a working comparison to catch any import errors before you rely on the new system alone.