When and how to migrate an asset spreadsheet into a managed system

An asset spreadsheet can contain years of useful history and years of improvised conventions at the same time. A migration should preserve what the organization can verify, expose what it cannot, and avoid turning inconsistent source data into authoritative-looking software records.

The goal is not merely to upload a file without an error message. The goal is to produce a target register whose identifiers, categories, people, locations, costs, dates, and current assignments can be reconciled with the approved source.

Before you migrate: signs you have outgrown the spreadsheet

A spreadsheet is not automatically a bad asset system. It is inexpensive, familiar, and easy to inspect, and for a stable inventory maintained by one person it may be exactly enough. The decision to replace it should rest on what the file fails to support, not on a generic asset count.

The common signs are:

• Handoffs overwrite the history. A row has one Assigned to and one Location field, so every move erases the path that produced the current value. Nobody can say who had the laptop before the current employee, or when damage was first noticed.
• Several versions claim to be current. Shared-drive copies, emailed exports, and department extracts all look authoritative. If people ask which file is current, the organization lacks a system of record, not better formatting.
• Important dates live somewhere else. Warranty, return, inspection, and renewal dates need separate calendar reminders that must stay synchronized with the file.
• Physical checks keep disagreeing with the file. Missing custodians, unknown locations, duplicate identifiers, and disposed items still marked active show that updates are not keeping pace with reality.
• Offboarding requires investigation. Identifying a leaver's equipment means searching purchase emails, asking managers, and comparing lists. The employee offboarding equipment checklist sets out what the register should support instead.
• Documents are separated from the events they prove. Receipts, repair invoices, inspection photos, and disposal certificates sit in folders the register can only hyperlink to.
• The register depends on one person's memory. Abbreviations, colour rules, hidden tabs, and the meaning of a blank field are known only to whoever built it.

Answer each question below with yes, sometimes, or no:

Several weak answers do not automatically require new software; some are ownership and policy problems that a new application will not fix. Test the process on one category first, as the simple asset management guide describes. If a shared file still cannot preserve the accountability and history the work needs, the steps below take the register into a maintained system without losing what it already holds.

1. Preserve the source and define ownership

Before cleaning anything, save a read-only copy of every source file with the collection date and owner. Record which file is authoritative when values conflict.

Create a migration decision log with:

Do not let the person editing the file silently decide policy while cleaning rows.

2. Define the target record

Start with the asset register template. Identify which source column maps to each target field, which fields are required, and which values are controlled.

Use a mapping table:

If a target field has no reliable source, leave it blank or create a documented follow-up. Do not manufacture precision.

3. Clean without destroying evidence

Work on a copy and retain the original row reference. That reference lets the reviewer trace a target record back to the source when a value is questioned.

Normalize text deliberately

• trim leading and trailing spaces;
• standardize obvious capitalization only when meaning is unchanged;
• map approved category, status, condition, person, and location values;
• keep identifiers and serial numbers as text;
• separate compound fields only when the rule is documented;
• preserve meaningful punctuation in names and identifiers.

The free asset register checker finds duplicate tags and serials, unreadable costs and dates, and variant spellings of the same location or category, and writes a cleaned copy while leaving the original untouched.

Find duplicates conservatively

Potential duplicate signals include matching asset tags, serial numbers, or a combination of manufacturer, model, and source reference. None is universally sufficient for automatic deletion.

Classify each suspected duplicate as:

• the same asset recorded twice;
• two distinct assets sharing incomplete information;
• an old record for a replacement asset;
• a parent and component relationship;
• an unresolved exception.

Retain the evidence behind the decision.

Separate current state from history

A spreadsheet may contain comments such as Moved from Denver; repaired 4/12; now with Jamie. Do not squeeze that text into the current location or custodian. Extract only facts the team can verify, and preserve historical events separately when the target system supports them.

4. Prepare people, locations, and categories

Assignments fail when the asset file references people or locations that do not exist consistently in the target system.

Before importing assets:

• approve category names and required fields;
• approve the people list and a unique matching rule;
• approve locations and sublocations;
• decide how inactive people and closed sites are handled;
• identify storage locations separately from deployed locations;
• document whether the import may create missing records automatically.

Names alone may be ambiguous. Use an approved unique field when available, but do not add personal data merely to simplify matching.

5. Import a representative batch

Choose records that expose variation:

• more than one category;
• assigned and unassigned items;
• several locations;
• missing optional values;
• custom fields;
• different date and cost patterns;
• at least one known exception.

The batch should be small enough to inspect row by row but representative enough to challenge the mapping. A clean set of identical records proves very little.

6. Validate before processing

Treat validation messages as useful evidence. Correct the source or mapping, not merely the cell that caused the first error.

For each validation issue, record:

• source row;
• field and rejected value;
• reason;
• correction or exception decision;
• reviewer when the decision changes meaning.

If the same error occurs repeatedly, update the transformation rule and rerun the representative batch rather than fixing hundreds of rows manually.

7. Reconcile the imported result

A processed import still requires reconciliation. Compare:

• source rows, accepted rows, rejected rows, and target records;
• unique asset identifiers;
• counts by category and status;
• counts by person and location;
• total purchase cost when the source is reliable enough for that comparison;
• missing required fields;
• sample custom-field values;
• assignments and historical notes that were intentionally excluded.

Inspect representative records in the application. Confirm that identifiers were not reformatted, dates were interpreted correctly, people and locations matched the intended records, and permissions show the right information to the right users.

8. Plan cutover and rollback

Define when the source spreadsheet stops accepting ordinary updates. A period where both systems are edited without a reconciliation rule creates two competing records.

The cutover plan should state:

1. final source collection time;
2. person who approves the final import;
3. changes allowed during the freeze;
4. process for recording urgent handoffs during cutover;
5. reconciliation and acceptance criteria;
6. rollback owner and retained source files;
7. date the legacy file becomes read-only reference material.

Do not delete the source after a successful import. Retain it according to the organization's records and privacy policies.

Migration checklist

Prepare

• Save read-only source copies with owners and dates.
• Choose the authoritative source.
• Define target fields and controlled values.
• Create the source-to-target mapping.
• Approve duplicate and exception rules.
• Prepare categories, people, and locations.

Pilot

• Select a representative batch.
• Validate the file before processing.
• Record and resolve every error class.
• Import and inspect representative target records.
• Reconcile counts, identifiers, assignments, dates, and costs.
• Obtain review from someone other than the preparer.

Cut over

• Define the update freeze and urgent-change process.
• Import the approved final file.
• Reconcile again after final processing.
• Keep unresolved rows visible with owners.
• Make the legacy file read-only.
• Schedule the first exception and physical verification review.

Migrating into AssetCenter

AssetCenter imports assets, subscriptions, locations, and people through separate Excel templates. The product workflow includes a validation step before processing, and asset imports can work with category custom fields when the template header matches the configured field name.

Follow the current bulk-import manual for the supported template and product steps. Use asset categories and custom category fields to prepare the target structure before importing the final file.

Next step: reconcile one representative category

Choose one category, build the mapping, and complete the full cycle from source preservation through target reconciliation. Do not expand until a second reviewer can trace the imported records back to the source and explain every rejected or intentionally excluded row.

When the process is sound, AssetCenter's fixed asset management page explains the operational record and product boundaries, and the pricing page provides the current limits for a wider rollout.

By Jeremy Francis

Founder & CEO, AssetCenter