Moving to ServiceNow Hardware Asset Management: Migration Considerations

Moving hardware tracking into ServiceNow Hardware Asset Management means replacing a spreadsheet, a legacy asset tool or a mix of discovery and manual records with one inventory. This guide helps the migration team decide what to inventory first, how to clean legacy records, how to map fields and how to cut over in a way that can be reversed.

What to Inventory in Your Current Hardware Practice

Before migrating to Hardware Asset Management, inventory how hardware is currently tracked: in a spreadsheet, in a legacy asset management tool, via discovery, or a combination. Determine what attributes you are currently tracking: asset tag, serial number, make and model, purchase date, warranty expiration, assigned user or location, cost.

Also inventory your hardware landscape: how many hardware assets, how many locations are they distributed across, how frequently does hardware change hands (due to employee moves, equipment upgrades, or decommissioning)? Understanding this landscape helps you estimate the scope of migration and plan accordingly.

Identify the biggest pain points: what is difficult about your current process? Lost assets, incorrect tracking, inability to track warranty status, difficulty with decommissioning compliance? Use these pain points to prioritize what Hardware Asset Management must improve.

Asset Discovery Versus Manual Entry

Hardware Asset Management data can come from automated discovery (scanning networks, cloud platforms) or manual entry. Large fleets are best discovered; small or highly distributed assets might require manual entry. Most organizations use a hybrid: discovery for network-connected devices, manual entry for mobile devices or assets at remote locations.

Plan your discovery strategy: which networks will be scanned, which locations have assets to discover, what credentials are needed for discovery? Test discovery on a subset of assets before running fleet-wide so you can tune the process.

For assets that cannot be auto-discovered (mobile devices, remote assets), plan a manual process: how will users or location managers report assets to Hardware Asset Management? Will it be a form submission, a mobile app, or periodic email submissions? Make the process as simple as possible or adoption will suffer.

Data Consolidation and Deduplication

If you are migrating from a legacy system, you will have a list of historical assets. Some of these may be duplicates—the same asset tracked in two places under different asset tags or serial numbers. You will also have retired or decommissioned assets that should not be migrated into the new system.

Plan a data cleanup phase: export asset data from the legacy system, deduplicate based on serial number or unique identifiers, remove retired assets, and validate that remaining records are accurate. The time this phase takes grows with the size of the asset base. Do not skip it; migrating dirty data into Hardware Asset Management perpetuates the problem.

Lifecycle and Status Definition

Define how your organization manages hardware lifecycle: when is a new asset purchased and added to inventory, when is it assigned to a user or location, when is it considered end-of-life and decommissioned? Document the lifecycle as a state machine in Hardware Asset Management so tracking is consistent.

Also define depreciation and warranty tracking: when should you expect hardware to need replacement? After how long does warranty expire? Use this information to proactively plan replacements before hardware fails.

Cutover Planning and Validation

Plan your cutover: will you migrate all assets at once (big bang) or in phases by location or asset type? For distributed environments, phased migration is often safer: migrate one location, validate accuracy, then move to the next location. This allows you to identify and fix issues on a smaller scale before affecting the entire organization.

Before cutover, conduct a spot-check: compare migrated asset records against physical assets in a location. Pick 2-3 locations and verify that every asset in Hardware Asset Management exists physically and that every physical asset is in Hardware Asset Management. If accuracy is below 95, postpone full migration and focus on data cleanup.

Post-Migration Support and Adoption

After migration, provide support: help users and location managers understand the new system, answer questions, and troubleshoot issues. Assign migration champions in each location who can help their peers adapt to the new process.

Also establish ownership: who is responsible for keeping Hardware Asset Management accurate? In distributed organizations, this is typically location managers or user’s direct managers. Make accountability clear and provide tools (mobile app, simple form) to make updates easy.

FAQ

Q: Should we use discovery or manual entry for our hardware assets?

Use discovery for network-connected hardware: servers, switches, desktops, printers. These can be discovered automatically and kept current. Use manual entry or imports for mobile devices, remote assets, or hardware not on the network. Most organizations use both: discovery for infrastructure, manual for everything else.

Q: What data should we migrate from the legacy system?

Migrate current assets: asset tag, serial number, make and model, purchase date, warranty date, current location or user assignment. Do not migrate retired assets or duplicates. Consider not migrating very old historical data; archive it separately for audit purposes but do not clutter the current inventory.

Q: How do we prevent asset tracking from becoming stale?

Make it easy to update: provide mobile app so users can update their own asset information, have location managers review and update assets quarterly, and use discovery to automatically refresh network-connected asset data. Also create accountability: track which assets haven’t been updated recently and investigate.

Mapping legacy fields before any record moves

Many migration disputes trace back to a field that meant one thing in the old tool and something slightly different in the new one. A legacy status called “stored” may mean on a shelf in IT, or it may mean assigned but not yet collected. Before loading anything, build a field map that lists each legacy field, the hardware record field it lands in, and the status values that will translate to each choice in the new instance. Mark every mapping where the two meanings are not identical, because those are the rows that need a human decision.

Running the old and new records in parallel

A parallel run is the step that is often skipped, and the one that catches the errors a field map cannot predict. For a defined period, both the legacy tool and the new hardware records stay open, and anyone who changes a device in one must make the same change in the other. The point is not to keep two systems forever. It is to learn, on real activity, which movements the new process handles badly. Good candidates to watch are hardware returned from leavers, devices moved between sites, and repairs that go out to a vendor and come back under a new serial number.

Keep a simple log during the parallel run. Each discrepancy gets a row with the device identifier, the field that differs, the cause and the owner of the fix, and the owner should be the person the roles and responsibilities guide identifies for that data. When the log stops growing for the classes of device that matter most, the new process is ready to become the only source of record.

A cutover sequence that can be reversed

A cutover is safer when the team can describe, before it starts, how to go back. The sequence below keeps the legacy tool readable until the new records have been checked against physical stock.

1. Freeze the legacy tool for new purchases and disposals, and publish the freeze date to procurement and the service desk.
2. Export the final legacy snapshot and store it read-only, with the export date and record count written on it.
3. Load the mapped records into a staging area and compare counts by class, site and status against the snapshot.
4. Carry out a physical check of a sample at each site, and treat any device that is missing or unlisted as a blocking defect.
5. Promote the staged records to live only after the defects from step four are closed or formally accepted by the owner.
6. Keep the legacy tool read-only for the agreed retention period, so that a reversal means re-pointing processes, not reconstructing data.

Deciding what to leave behind

Not every legacy record deserves a place in the new module. Records for devices disposed of before the cutover should move to an archive, not into the active inventory. Duplicate records for one physical device need a survivor rule agreed in advance, for example keeping the record with the most recent verified location. Open purchase orders for hardware that has not yet arrived are often better handled by letting procurement finish them in the old flow, then creating the hardware records on receipt. Writing these rules down before the load avoids arguments over individual records during it. The acceptance tests for the load itself are easier to design when they follow the same rules.

Questions migration teams ask after the first load

Why does the count match but the holders do not?

The counts are checking that records arrived, not that they are linked correctly. Holder links fail when the names or employee identifiers in the legacy data do not match the user records in the new instance, which often happens after a directory change. Compare the unmatched holders as a separate list and resolve them before judging the load a success.

Should historical depreciation be migrated?

That decision belongs to finance, not the migration team. Some organizations carry the recorded cost and start date across and recalculate from there. Others restate values. Either approach can work, but the choice must be recorded before the load, because it determines how the first post-migration financial report reconciles.

What if a site refuses to use the new process?

Treat the refusal as a process signal. Often the new intake step takes longer than the old one, or the site has a local practice the design did not account for. Ask the site lead what the old process did that the new one does not, and decide whether the gap is a design fault or a reason to keep that site in the legacy tool for one more cycle.

For the data-quality side of the same move, the troubleshooting guide covers the data quality problems that appear after go-live, such as unrecorded assets and decommissioned assets still in the system.

Related guides: ServiceNow Hardware Asset Management Testing and Acceptance Checklist.