From spreadsheets to a real dashboard: a migration guide for owners

Moving off spreadsheets is a five-step sequence, and the order matters more than the tooling. Audit the workbooks you actually use and find out who maintains each one. Define the short list of numbers worth watching. Name a single source of truth for each type of data. Decide, per source, whether it can be connected automatically or must be re-keyed. Then roll out one entity and one metric at a time, running in parallel until the new figures match the old ones. Skip the first three steps and you will end up with a prettier version of the same mess, which is the usual reason these projects disappoint.

Step one: audit what you already have

Open every workbook that touches the business and write down four things about each: what question it answers, who updates it, how often, and where its inputs come from. Most owners find between six and twenty files, several of which nobody has opened this year, and one which turns out to be load-bearing for the entire operation.

Two patterns will emerge. Some sheets are genuine data entry — the only place a fact exists. Others are derived views that copy from elsewhere. Only the first group needs migrating; the second group is what the dashboard replaces. Separating them early prevents you from rebuilding reports that exist purely because someone could not see the underlying data.

Step two: define the numbers that matter

Write the list before anyone touches software, and keep it short. For each metric, record its exact definition, the period it covers, and how it is grouped — by property, by entity, by business line. Ambiguity here becomes an argument later, because a term like 'net' means at least three different things depending on who is asked.

If you need a starting point, the KPIs every multi-property owner should track is the list we would begin from for a rental portfolio. Adapt it rather than adopting it — the value comes from the definitions being yours.

Step three: pick one source of truth per data type

This is the decision the whole project rests on. For every kind of data, one system is authoritative and everything else defers to it.

• Bookings and availability: the reservation system or channel manager, never a calendar copy.
• Money in and out: the accounting file, reconciled against bank feeds.
• Properties, units and ownership: one canonical list with entity, ownership split and service dates.
• People: owners, guests, tenants and staff each in one place, with a stable identifier.
• Maintenance: the work-order system or ticket list, with cost attached to the property.

Where two systems both hold something, pick one and make the other read-only. Where nothing holds it, create the list before you build any view on top of it. The canonical property list is the piece most operations are missing, and it is the one that makes every roll-up possible.

Step four: connect or re-key?

Not everything can be connected, and pretending otherwise stalls projects. Go through each source and put it in one of three buckets: has a usable API or export that can run on a schedule; can be imported periodically with a file; must be entered by a human because the source is a PDF, a portal with no export, or a phone call.

For the third bucket, do not try to eliminate the human — make the entry structured. A short form that writes into the system beats a spreadsheet cell, because it validates, timestamps and attributes. Manual data is fine as long as it enters once, in one place, in a known shape.

Be equally honest about history. Migrating years of transactions is often expensive and rarely used. A common compromise is to bring across the current and prior year in full, keep older data archived and queryable, and accept that the deep history lives in the accounting system where it already is.

Step five: roll out in phases and run in parallel

Choose one entity and the two or three metrics you check most often. Build those, then run them alongside the spreadsheet for a full reporting cycle and reconcile the difference every time they disagree. Every discrepancy is either a bug in the new system or an error in the old one, and it is very often the second.

Only when a cycle closes clean do you add the next entity or the next metric. This is slower on paper and faster in practice, because the alternative — a big-bang switch across everything — produces a system nobody trusts and a quiet return to the spreadsheets within a month.

What usually goes wrong?

• Rebuilding the spreadsheet exactly, quirks included, instead of asking what each view is for.
• Letting the dashboard become a data entry point, which recreates the two-versions-of-the-truth problem.
• Launching with too many charts, so nobody knows which numbers are trustworthy.
• No named owner for the data, so definitions drift and nobody reconciles the exceptions.
• Migrating all history because it feels safer, then spending the budget on data nobody looks at.

How long does this take?

The audit and definition work takes a couple of focused sessions and is the highest-leverage time you will spend. The build depends entirely on how many sources connect cleanly and how unusual your structure is. What we can say plainly is that a first phase covering one entity and a handful of metrics is a weeks-scale project, not a year-long programme, and that phasing it is what keeps it that way.

If your portfolio spans rentals and other companies, the destination is a single owner view across all of it — that is what The Command Center is being built for. If it is mostly rentals, HostAmplify becomes the operating system underneath, and if it is a brokerage, BrokerHelm plays the same role. Whichever it is, the migration sequence above does not change.