Most data migration advice is about cleaning data before it moves. The bigger risk is losing the judgment calls a spreadsheet quietly encoded and structured intake never gets told about.
TL;DR
- A tracking spreadsheet is not just rows of dirty data. It encodes years of undocumented judgment: which vendor actually ships on time, which exceptions were approved and why, which “preferred” supplier nobody really uses anymore.
- Cleaning a spreadsheet before migration, the default advice, often deletes that judgment along with the mess, because the two are not visually distinguishable to whoever is doing the cleanup.
- Migrate structure and context together: map columns to intake fields first, then clean row by row against the new field definitions, not the other way around.
- Hackett Group’s 2026 Procurement Key Issues research: 76 percent of organizations report AI-driven improvements of 25 percent or more once adoption scales past pilot, gains that assume the underlying data made the move intact.
- The most common migration failure is not messy data. It is a clean system launched on top of context nobody bothered to carry over.
- See how Merlin Intake handles structured onboarding from ad-hoc sources. Request a demo →
It knows which vendor actually ships on time, whatever the “preferred supplier” list says. It knows which approval exceptions were routine and which ones caused problems. It knows why a category manager started routing certain requests around the official process, information that never made it into any policy document because nobody wrote it down, it just showed up as a pattern in the sheet if you knew to look for it and had been around long enough to recognize it.
Most data migration advice starts with cleanup: fix inconsistent formats, remove duplicates, standardize vendor names. That advice is not wrong, but it treats the spreadsheet purely as a data quality problem, when for most procurement teams it is also the only record of institutional judgment that exists anywhere, never written into a policy, never formally approved, just accumulated one workaround at a time by whoever was closest to the actual work.
Why does cleaning the spreadsheet first go wrong?
Because cleanup and judgment look identical from the outside to anyone without the full history. A “duplicate” vendor entry might be an actual duplicate, or it might be two legitimate divisions of the same supplier that get ordered from differently for good reason, one handling hardware, the other handling support contracts, both correctly listed as separate rows. An “inconsistent” category tag might be a data entry error, or it might reflect a real distinction someone made deliberately that the standard taxonomy never accounted for, a workaround built by someone solving a real problem the official categories did not anticipate.
Whoever runs the cleanup, often someone without the tribal knowledge of whoever built the spreadsheet, cannot reliably tell the two apart, and errs toward standardizing everything, which quietly erases the second category along with the first. Nobody notices at the time, because a cleaned-up spreadsheet looks strictly better than a messy one. The gap only shows up months later, as a routing rule that keeps producing wrong results for reasons nobody can explain anymore.
What should actually move first, structure or data?
Structure. Map the spreadsheet’s columns to the new system’s intake fields before touching a single row of data. This surfaces the real gaps early: a column the spreadsheet has that intake has no field for usually contains exactly the kind of undocumented judgment worth preserving deliberately, not losing by omission. A field intake requires that the spreadsheet never captured is a genuine gap that needs a decision, not a guess made during a rushed cleanup pass under deadline pressure.
This reordering costs almost nothing extra in calendar time. It is the same two tasks, structure mapping and data cleanup, done in the sequence that lets each one inform the other, rather than cleanup happening blind and mapping happening afterward against whatever survived.
Figure 1: structure first, then clean row by row against it.
How do you migrate the judgment calls, not just the rows?
Interview the people who actually used the spreadsheet before archiving it, not after. Ask what the color-coding meant, why certain rows have notes nobody else would understand, which “exceptions” column entries were really exceptions versus routine workarounds for a process that did not fit reality. This takes a few hours per spreadsheet owner, spread across however many people actually touched the file regularly, not just whoever officially owns it on paper.
It is cheaper than rediscovering the same judgment six months later through a wave of support tickets and repeated policy exceptions that structured intake was supposed to prevent in the first place. A short interview up front replaces a long tail of one-off corrections that each look like an isolated bug until someone notices they all trace back to the same missing piece of context.
Deloitte’s 2025 Global Chief Procurement Officer Survey found organizations that combine technology and talent investment, Digital Masters in the survey’s terms, met or exceeded cost-savings targets 96 percent of the time, against 80 percent for organizations that had not. That gap is a broader finding about digital investment generally, not migration specifically, but the mechanism lines up: the organizations getting more from a new system are consistently the ones that invested in more than the software purchase itself.
How does this connect to what structured intake actually needs?
This is where the mapping work pays off directly. Merlin Intake captures requests against defined fields, category, preferred vendor, approval routing, from the first request onward. Whatever gets migrated into those fields is what the routing and policy engine will act on immediately, which is exactly why moving undifferentiated rows without first deciding what each column actually means produces a system that runs, technically, but enforces last year’s undocumented workarounds as if they were this year’s deliberate policy.
APQC benchmarking data puts the cost of processing a single purchase order between roughly 14 and 54 dollars, a range attributed to how procurement work is structured and executed. A migration that carries forward ambiguous or wrong data does not avoid that cost, it just moves it downstream to whoever eventually discovers the routing rule was built on a mistaken assumption, usually a category manager troubleshooting why a request keeps landing somewhere it should not.
Because Merlin Intake sits inside the Merlin Agentic AI Platform, a migration decision made here is not isolated to intake. The same supplier and category data feeds sourcing and contract records elsewhere in the platform, which is one more reason a rushed, structure-blind migration is more expensive to unwind later than it looks at the outset, the mistake does not stay contained to one module.
What does a realistic migration timeline actually look like?
Longer than the technical export-and-import step suggests, and that is normal, not a sign something is going wrong. Budget real time for the interviews, the structure mapping, and a pilot category run against the newly mapped fields before committing the full spreadsheet, the same logic a phased software rollout uses, applied to the data feeding it rather than the software itself. Teams that treat migration as a single weekend project tend to be the same ones fielding confused support tickets a few months later, tracing each one back to a decision that got made silently during a rushed cleanup pass instead of deliberately during mapping.
A single pilot category, run through the newly mapped fields before the rest of the spreadsheet follows, catches most of the remaining problems cheaply. It surfaces exactly the kind of edge case an interview might have missed, at a point where fixing it means adjusting one category’s mapping rather than reworking a system already live for the whole organization.
Where does this approach have real limits?
Not every spreadsheet is worth this level of care. A tracking sheet that is genuinely just a list, with no undocumented judgment behind it, does not need spreadsheet-owner interviews before migrating; cleaning and mapping alone are enough, and adding an interview step would just be overhead with nothing to recover. The interview step earns its cost specifically for spreadsheets that have been the de facto system of record for a category or process for years, where the accumulated judgment is real, informal, and would actually cost something to lose.
Frequently Asked Questions
Q1. Should I clean my spreadsheet before migrating it to a new system?
Map its columns to your new system’s fields first. Cleaning before mapping risks erasing legitimate exceptions and undocumented judgment along with genuine errors, since the two are not easy to tell apart without that context.
Q2. What is the biggest risk in procurement data migration?
Losing undocumented institutional knowledge, which vendors are actually reliable, which exceptions were routine, that a spreadsheet encoded informally but a clean data migration does not automatically preserve.
Q3. How long should a spreadsheet-to-intake migration take?
Longer than the technical steps alone suggest. Budget time for structure mapping and interviews with the people who used the spreadsheet, not just the data export and import.
Q4. Who should be involved in a data migration from spreadsheets?
The people who actually used and maintained the spreadsheet, not only IT or the project team, since they hold the context behind entries that look inconsistent but were often deliberate.
Q5. What data should never be migrated as-is?
Free-text fields that were never mapped to a controlled taxonomy, since importing them unchanged usually just relocates ambiguity into the new system rather than resolving it.
Q6. Does Merlin Intake support migrating from ad-hoc spreadsheets?
Yes, Merlin Intake is built to onboard structured requests from existing sources, which is why mapping spreadsheet columns to its intake fields before migrating data is the recommended starting point.
Q7. What happens if I skip the structure-mapping step?
The new system typically launches on schedule but enforces whatever ambiguity or outdated workaround was in the original data, since nothing forced a decision about what each field actually meant before it went live.
Q8. Is spreadsheet migration a one-time project or an ongoing process?
Treat the initial move as a one-time project, but expect a follow-up review once real usage surfaces gaps the original mapping missed, which is normal rather than a sign the first pass failed.
