Migrating from Spreadsheets to a PM Tool
Every agency I have audited runs at least one piece of delivery on a spreadsheet, and in the smallest ones it is usually the whole operation. That is not a criticism. A spreadsheet got you from three people to fifteen on nothing but a login and a bit of discipline, and it is honest to say a piece of it should survive whatever you migrate to next.
I have spent twelve years running delivery operations inside marketing agencies, and across 92 completed engagements as a consultant the pattern is consistent: agencies do not wear out a spreadsheet because they picked the wrong template. They wear it out because delivery tracking eventually needs something a spreadsheet was never built to do, and there is a specific point where forcing it stops being worth the familiarity.
Which tool you land on next is a separate decision. I have written up the criteria I would actually score a candidate against in the project management software buyer’s guide. This piece is about the move itself: what to keep doing in a spreadsheet, what has genuinely outgrown one, what to carry over versus rebuild versus leave behind, and how to get from one system to the other without losing a quarter to it.
What is a spreadsheet still the best tool in the building for?
Say this plainly before anything else, because a piece that treats spreadsheets as an embarrassment loses the reader who is still running one, and rightly so. There are jobs a spreadsheet does better than any work-management tool you could buy.
- Modeling and forecasting. A hiring plan, a pricing scenario, a capacity model where three variables move against each other at once. That is what a grid of formulas is for, and no board view replaces it.
- One-off analysis. A single client’s project economics, a one-time margin review, a question you need answered today and will never ask again in that exact shape. Building a permanent structure for a question you will only ask once is waste, not rigor.
- Anything whose shape changes weekly. A launch checklist you are still inventing as you go, a pilot process you have not standardized yet. A spreadsheet lets you add a column on Tuesday without anyone’s permission. A configured system punishes you for doing that.
- A fast answer to a single question. Sometimes leadership just wants to know one number by end of day, and the fastest honest path to it is a quick pivot table, not a new dashboard built for reuse.
None of that goes away when you migrate delivery tracking. This is not an argument to retire spreadsheets. It is an argument to stop asking one to do a second job it was never built for, while it keeps doing the first job well.
What are the signals you have actually outgrown it?
Delivery tracking is a different job from modeling. It needs to answer, at any moment, without anyone stopping to look it up: where is this, who owns it, how long has it been there, and what changed. A spreadsheet can display that information for a while. It cannot maintain it, and four specific signals tell you when the gap has become the real cost.
- Version confusion. Copies with names like “Master_v3_FINAL” circulate by email or shared drive, two people edit at once, and someone reports a status that contradicts the file another person has open right now. Nobody can say with confidence which copy is current, because currency was never a property the file had, only a claim someone made about it.
- No per-item ownership. A column labeled “owner” is a label, not a system. Nothing surfaces to that person when a stage changes, nothing flags a task that has sat untouched for two weeks. The sheet shows you a name. It does not act on one.
- No history. A cell gets overwritten and the fact that a task sat in review for eleven days before it moved is gone. It existed nowhere except in the memory of whoever happened to notice, and that memory does not show up in a client update or a leadership report.
- Reporting that means re-keying. Producing a client status update or a leadership dashboard means opening the tracker, reading it, and typing the summary into a different document, every week, for every active project. That is manual translation, not reporting, and it is the clearest sign the sheet became a system of record without ever becoming a system of visibility.
One of these on a bad week is not a verdict. All four showing up together, and continuing to show up cycle after cycle, is not a discipline problem you fix with a cleaner template. That is the format arguing with the job you are asking it to do.
What do you migrate, what do you rebuild, and what do you abandon?
Treat the old spreadsheet as three separate piles, not one file to import wholesale. A straight import drags the spreadsheet’s habits into a tool built to break them, and you end up with a system that has a login screen and none of the benefits.
| Bucket | What belongs there | Why |
|---|---|---|
| Migrate | Active client and project list, the open task inventory, the taxonomy that already works: service lines, client names, team roster | This is current, correct, and referenced daily. Re-typing it by hand just introduces new errors into data that was already right. |
| Rebuild | The workflow structure itself (the stages work actually moves through), your recurring reports, any client-facing status format | These should reflect how the new tool actually surfaces information, not be recreated column for column from the old sheet. Rebuilding here is the whole point of moving. |
| Abandon | Closed and historical rows, one-off calculators and ad hoc models, anything nobody has opened in six months | Old data belongs in a read-only archive, searchable if genuinely needed. Calculators were never delivery tracking and should stay in spreadsheet form, on their own. |
Deciding which bucket something falls into is closer to business process improvement consulting than it is to software setup. It is a decision about how work should move, not which fields a new tool happens to offer, and it is worth making deliberately before the first board gets built. A workflow copied field for field from a spreadsheet is still a spreadsheet. It has just added a login.
Why run both systems for one full cycle before you cut anything over?
Do not big-bang this. Run the spreadsheet and the new tool in parallel for one full delivery cycle, whatever a cycle means for your agency: a sprint, a month of retainer work, one full client project start to finish. The spreadsheet stays the record of truth for anything leaving the building, client reports, leadership numbers, while the new tool gets populated with live, real work so people can see whether it actually reflects reality on an ordinary Tuesday, not just in a clean demo.
The parallel run is answering one question honestly: does the team update the new tool without being chased, and do the numbers in it match the spreadsheet’s numbers at the end of the cycle. If they diverge, you now know exactly where, while the spreadsheet is still sitting there to check against. Find that out during a supervised trial run, not eight months into treating the new tool as the only record.
What tends to break after the parallel run ends, once the tool is live on its own and the honeymoon wears off, follows a specific and repeatable pattern. I have written that up separately, in full, rather than compress it here: why agency PM tool implementations fail.
What does cutover day actually look like?
Pick an actual date. Not “once everyone’s comfortable,” which never arrives on its own, but a specific day announced in advance.
- Freeze the spreadsheet, do not delete it. Keep it read-only as an archive people can consult for a historical question. Stop editing it as of the cutover date, full stop.
- Point every recurring report at the new tool’s live view. Not a re-keyed copy of it. If a report still gets built by hand after cutover, the cutover has not actually happened for that piece of work.
- Tell clients and leadership where the number is now coming from. A formatting change between two systems can look like a spike or a drop if nobody explains the source moved. State it plainly before the first post-cutover report goes out.
Treat the freeze as a hard line, not a suggestion. Anyone reporting a status that only exists in the old file does not have a current status. That is the entire point of the move: one place people trust, instead of two places people reconcile by hand.
So when do you actually make the move?
Not on a calendar, and not at a headcount. Move when the signals are chronic rather than occasional: version confusion is a running joke rather than a one-off, ownership genuinely lives nowhere, nobody can answer how long something has been stuck without asking around, and someone spends real hours every week re-typing the same numbers into a different document.
One of those on a rough week is not a verdict. Two or more showing up every single cycle is.
If none of that describes your agency, the honest answer is to leave the spreadsheet exactly where it is, doing the job it is genuinely good at, and put your energy into getting more disciplined about how you use it, not into shopping for a tool you do not need yet. A spreadsheet you have outgrown looks nothing like a spreadsheet you are simply not using well. Confusing the two is how agencies end up migrating a process that was never actually broken.
Where to start
Deciding what to migrate, rebuild, and abandon, and getting an honest outside read on whether your signals actually justify the move rather than just the itch to buy something new, is the first conversation inside the Agency Ops Audit: a $1,500 fixed-fee review, two weeks, a written 90-day roadmap, and a 60-minute readout call.
It answers the question this piece cannot answer for you from a distance. Not whether spreadsheets are bad, because they are not, but whether yours has actually reached the point where the cost of the workaround has become higher than the cost of the move.
