Every vendor risk program starts in a spreadsheet, and the spreadsheet is not the mistake. It is the correct tool for 20 vendors and one owner. The mistake is staying in it past the point where the failure modes turn from annoying to dangerous: silent version forks, formulas that break when someone inserts a column, reassessment dates nobody is watching, and an audit trail that consists of "last modified by."
The signs you have crossed that point are consistent: your vendor list passed 50, more than one person edits the file, an auditor or a customer has asked for evidence the spreadsheet cannot produce, or you discovered two versions of the truth in two different folders. What follows is a staged migration plan that gets you out without losing history, and without the classic failure of importing a mess into expensive software and calling it progress.
The prime directive: clean before you move
A platform does not fix bad data. It gives bad data better formatting and an API. Every stage below exists to enforce one rule: nothing enters the new system that has not been deliberately decided. Plan for the cleanup to take longer than the import. In practice the split is roughly 70 percent cleanup, 30 percent everything else, and teams that invert that ratio spend their first platform year distrusting their own records.
Stage 1: Freeze and consolidate (week 1)
- Declare a single source file. Pick the most complete version, announce it, and lock every other copy read-only. Version forks created during migration are the number one cause of missing vendors afterward.
- Hunt shadow inventories. Pull vendor names from accounts payable, your SSO application list, and procurement contracts, then diff against the spreadsheet. Expect surprises. It is common for finance to know 20 to 40 percent more vendors than the risk register does, an illustrative range but a consistently directionally correct one.
- Dedupe by legal entity. "AWS," "Amazon Web Services," and "Amazon" are one vendor. Subsidiaries with separate contracts and separate data flows are not. Decide the rule, write it down, apply it once.
Stage 2: Field mapping and data hygiene (weeks 2 to 3)
Now map spreadsheet columns to platform fields. Do not map everything. Every free-text column you carry forward is a future report you cannot run. Use a three-bucket triage:
| Bucket | Rule | Examples |
|---|---|---|
| Migrate as structured data | Field drives a workflow, report, or SLA | Vendor name, owner, tier, data classification, contract renewal date, last assessment date |
| Migrate as attachment or note | Historical value, no workflow value | Old assessment PDFs, email threads, legacy scoring rationale |
| Leave behind | Nobody can explain what it means | The "Status2" column, color coding with no legend, columns last touched in 2023 |
Two hygiene rules pay for themselves immediately. First, normalize every enumerated field: if the criticality column contains "High," "high," "HIGH," and "Hi," collapse them now, because the platform will treat those as four values. Second, every vendor gets a named human owner before import. "IT" is not an owner. Unowned vendors are how reassessments silently lapse, which is the same staffing trap described in scaling a third-party risk program without growing your team.
Stage 3: Re-validate tiers before they harden (week 3)
Migration is the one natural moment to challenge tier assignments, because after import the tiers become the engine that drives assessment depth, reassessment cadence, and monitoring intensity. Spreadsheet tiers drift: they were assigned years ago, by different people, often reflecting spend rather than impact.
Run a fast re-validation pass. For each vendor answer three questions: what data of ours do they hold, what happens on day one if they go dark, and do they connect to our environment? If the recorded tier disagrees with those answers, fix it now. A full methodology is in our vendor tiering framework; even a rough pass beats importing stale tiers, because platforms are very good at faithfully automating yesterday's misjudgments.
Stage 4: Cutover, in the right order (week 4)
Do not import everything and then figure the platform out. Cut over in a deliberate sequence, validating each layer before the next:
- Vendor records first. Names, owners, tiers, core attributes. Verify counts: the platform total must equal the cleaned spreadsheet total, and any difference must be explained, not shrugged at.
- Contracts and renewal dates second. These drive the calendar and give the platform immediate daily value.
- Open findings and remediation items third. Open items need workflow. Migrate them with their original open dates, not the import date, or your aging metrics start life as fiction.
- Historical assessments last, as attachments. Do not re-key old questionnaires into structured form. The effort is enormous and the analytical value is low. History is for evidence, not analytics.
Run the spreadsheet and the platform in parallel for two weeks, with the spreadsheet formally read-only. Anyone who needs a change makes it in the platform. This is a behavioral cutover, not a technical one, and it is the stage where migrations actually fail.
The first 30 days: prove the platform earns its keep
The first month decides whether the platform becomes the system of record or an expensive mirror of a spreadsheet that quietly comes back to life. Three moves:
- Turn on the clock. Configure reassessment schedules and renewal reminders from the tier cadence in week one. Automated nagging is the single most tangible thing a platform does that a spreadsheet cannot.
- Send the next real assessment through the platform. Not a pilot, not a test vendor. The next genuinely due assessment. Nothing validates field mapping like production use.
- Ship one report the spreadsheet could never produce. Coverage by tier with an audit trail behind every number is a good first candidate. Send it to your leadership unprompted. This is how the platform earns political permanence.
One selection note while you are choosing where to land: if vendor assessments will live in one tool and continuous monitoring signals in another, you are migrating from one fragmented state into a different fragmented state. Platforms built on a single vendor record, ThirdSentry among them, let the questionnaire answers, external signals, findings, and evidence you migrate stay joined, which is what makes the later analytics (coverage, divergence, concentration) possible without another integration project.
What to keep from the spreadsheet era
Keep the frozen final spreadsheet forever, timestamped, as the migration baseline an auditor can compare against. Keep the field-mapping document, because it is the answer to "where did this value come from" for the next two years. And keep the humility: the spreadsheet failed you slowly and quietly, and a platform can do the same if nobody owns data quality. The migration is finished when someone is named to own exactly that.
ThirdSentry imports vendor registers from CSV and Excel with tier, owner, and lifecycle fields mapped on the way in, then puts assessments, monitoring, findings, and evidence on that same record from day one. Teams following a plan like this one are typically live in weeks, an illustrative target the onboarding flow is built to deliver, not a promise that skips the cleanup.
