Sitearc

Runbook: move a maintenance tracker out of a spreadsheet

A filled column mapping, the migration order and the one column worth keeping. Taken from a real-shaped sheet of 240 rows.

Answers
Keep the tracker's decisions and stop maintaining its data by hand.
Included mapping
A filled column mapping and migration record
Written for
Agencies with a spreadsheet per client

What a spreadsheet is good at

A spreadsheet is a good record of decisions a person made. It is a poor copy of data a machine can read. That difference decides what you keep.

The mapping, filled in

Northline Studio, one client sheet, 240 rows, exported and retired on 2026-09-26.

sheet column          where it goes now
page url              the work item, from the crawl
issue text            the work item's change, kept verbatim
owner                 the person who decides
date raised           the item's created date
date shipped          the item's shipped date
notes                 the review thread on the item
impressions column    dropped: read from Search Console, with a date
position column       dropped: read from Search Console
rank column           dropped: read from the rank tracker
status dropdown       replaced by queue states

kept as history
- 240 rows exported to maintenance-history-2026-09.csv
- 41 open rows re-created as items
- 199 closed rows left in the export, not re-created

one column kept in a sheet
- "never doing this", 17 rows, with reasons. Reviewed twice a year.

The migration, in order

  1. Export the sheet, and keep the file where the client can reach it.
  2. Connect the sources before importing anything.
  3. Re-create only the open rows. Closed rows stay history.
  4. Run one cycle before adding rules or automation.
  5. Keep one sheet for deliberate refusals, and review it twice a year.

Acceptance: the migration is finished when

  • the export exists and is dated
  • every open row has a matching item, with the same owner
  • no closed row was imported, and the count matches
  • the manual metric columns are no longer maintained
  • one cycle has run since the import

Troubleshooting

Symptom Likely cause What to do
Duplicate items after import Two people maintained two sheets Reconcile open rows first
Owners are unknown The sheet used initials Map each initial to a person
Items arrive with no context The notes column was dropped Keep the notes as the first comment
Someone keeps typing metrics The old sheet is still shared Retire it, with a read-only copy
The refusal list grows Nothing is reviewed Put a review date on it

Limits

A migration cannot recover history the sheet never recorded.

If the client is attached to the sheet, keep it read-only for a quarter. The goal is to stop maintaining data by hand, not to win an argument.

Where this came from