How we run a large refactor: one workbook per phase, one assignee per row.
A large refactor lives or dies by how well the client can see progress. We do it with per-phase workbooks, an assignee column on every row, and a smoke test that runs itself. Here is the shape we've settled on and why.
The problem with a single scary spreadsheet
A large refactor — SEO, accessibility, a data-model rework — usually starts life as one enormous list of everything that's wrong. It's demoralising for the client, unactionable for the developer, and it tends to sit unread. Nobody wants to open a 900-row spreadsheet on a Tuesday morning.
One workbook per phase
So we don't ship one workbook. We ship several — one per phase of the rework, each with its own scope and its own definition of done. A metadata-and-schema pass is one workbook. Image cleanup is another. URL renames and redirects are a third. Each phase gets a start date, a finish date, and a spreadsheet you can actually finish reading.
Inside a workbook, we split by concern into sheets rather than by row-count. If a phase touches title tags, meta descriptions, canonical URLs, and Open Graph, those are four sheets, not one. This came out of direct client feedback on the first project we ran this way — 'create multiple sheets for the same phase in one file, and group changes' — and we've never gone back.
The assignee column
Every row on every sheet has an assignee column. It only ever holds one of two values — the developer or the client. That's the whole rule. If a change is on the developer, it's ours to ship. If it's on the client, we've written down what we need and nothing moves until it lands. Ambiguity about who owns a row is where refactors go to die; this column exists to make ambiguity impossible.
The smoke test that runs itself
The last thing we add to a phase is a smoke test. For a URL-rename phase, that means a script that walks every old URL and checks it returns a redirect to the right new URL, and every new URL returns a 200. We schedule the test to run itself after the phase ships — no human has to remember to run it. When the report lands, either every check passes or it names exactly which row didn't.
What this pattern is really doing
The workbook, the assignee, and the smoke test are the same idea from three angles: make progress visible without asking anyone to trust that it's happening. A client who can see the rows tick over is a client who doesn't have to check in. A developer who has one workbook open at a time is a developer who ships. And a smoke test that runs on its own is a claim the software backs up in writing.
When we use this, and when we don't
This shape earns its keep on any refactor with more than a couple of hundred rows of change, especially one with SEO or compliance risk if a row is missed. For a small change — five files, one afternoon — this is overkill. We work by feel for anything under that; the workbook is what we reach for when 'by feel' would let something slip.