Decide what belongs in the new system
Start with an untouched backup of the current files and a working copy for preparation. Identify the spreadsheets that people actually use, who maintains them and which decisions depend on them. A forgotten export and a current asset register should not automatically receive the same treatment.
Separate current assets, open work, recurring schedules and useful history from obsolete or duplicate records. Decide what must be searchable in the new system and what can remain in a controlled archive. Keep that decision documented so missing historical records are intentional rather than accidental.
Create a small data dictionary
Agree on stable identifiers before rearranging columns. An asset number should continue to identify the same equipment even when its description or location changes. Define the fields your team will maintain and the format that each field expects.
- Asset identifier and descriptive name, with a rule for duplicate names.
- Location and parent asset, including the intended hierarchy.
- Work-order status, priority and responsible team.
- Dates, time zones, units and meter-reading conventions.
- Document references and the owner of each source record.
- Rules for retired equipment and completed historical work.
Map and validate before the full import
Obtain the selected product’s current import template and accepted values. Do not assume that an export from the old tool matches the destination format. MaintainX’s work-order import documentation, for example, describes how certain supplied values can create related location records. That makes checking naming consistency before import particularly useful.
Choose a small sample that includes the cases likely to expose a problem: a parent-and-child asset, duplicate-looking names, an open job, a completed job, a recurring task and a document. Keep private operational details out of public demonstrations; use authorized test records or anonymized examples.
| Check | Expected evidence |
|---|---|
| Record counts | Accepted and rejected rows reconcile to the submitted sample. |
| Relationships | Jobs connect to the intended assets and locations. |
| Dates and values | Dates, units, statuses and priorities retain their intended meaning. |
| Access | The right users can find and update the imported records. |
| Exit | Required data can be exported in a usable format. |
Assign responsibility for corrections
Ask who will fix rejected rows, review duplicates and approve the result. Clarify whether the vendor’s implementation proposal includes data preparation, import execution, mapping assistance or only access to a template. These are different responsibilities.
Keep a record of the source file, mapping version, import date and corrections made. After a successful sample, repeat the checks on the larger dataset instead of assuming that additional rows behave identically. Retain the original files according to your organization’s established retention practices.
Plan the operational cutover
Choose when new maintenance work will start in the CMMS and how work already in progress will be handled. Tell the team which system is authoritative for requests and completion records during the transition. Unclear ownership can create duplicate jobs even when the data import itself is correct.
Agree on a fallback for interruptions and a way to reconcile any work captured outside the new system. Finish the transition only after the operational owner confirms that essential records, permissions and reporting are usable. A successful upload is one checkpoint, not the entire migration.