Migrating Your Data to Trimble Unity Maintain
Data migration from old systems into Trimble Unity Maintain is a large and complex task. Use our guide to help you through the process.
Migrating Your Data to Trimble Unity Maintain
![]()
Migrating from an aging Computerized Maintenance Management System (CMMS), spreadsheets, multiple other systems or even paper-based systems into Trimble Unity Maintain can be one of the most valuable upgrades that an organization can make. Ultimately, it brings your data together into one format and one location.
Success depends on preparation and process. This outline provides a framework for moving current data, in whichever form it resides, into Trimble Unity Maintain with clean data and minimal disruption.
1. Plan & Scope
As you start to think about your migration, define why you’re migrating data and let that determine what data you want to migrate. It’s important during this phase to establish the goals you want to achieve, whether they be better asset data visibility, mobile workflows, better outcome reporting or a myriad of other reasons. Having clearly defined goals will allow you to stay on course and provide a practical way to determine and measure success at the end of the process.
Next, identify which data sets are essential to migrate over and which are more “nice to have”.
You will also want to assign roles and responsibilities for decision-making during the identification stage. This will help avoid getting stalled at a particular stage, as well as holding people accountable throughout the process. Overall, this allows you to keep the process moving forward. More datasets will inevitably be discovered during identification, so it is critical to have a decision-making body in place to decide priority and criticality.
2. Assess & Prepare Data
Before migrating your data, you must understand the current state of your data. The first place to start is to inventory all your current data sources. This may be your legacy CMMS, spreadsheets, GIS data, ERP/Finance system or custom MS Access database. This isn’t a totally inclusive list. The goal here is to understand where your data is currently being held.
Some other key considerations are:
- Level of detail – do you need only an occurrence of a past work order, cost summaries or line-item level of detail?
- Accuracy of your source data – is all data worth bringing in? Decide what is critical and whether you need all extensive history or just the critical steps in repair history?
- Data mapping – what information is reportable? Are there specific fields you need to report on or do you just need reference data for lookup? This may allow you to compile certain fields into a comments field, rather than having everything in its own dedicated field.
Asset hierarchies, naming conventions and system codes should reside in Esri ArcGIS as the system of record. Because Unity Maintain connects directly to ArcGIS, organizations without a geographic information system (GIS) asset register may need to establish one before migration.
After noting where data is located and what you would like to migrate, you next need to audit the quality of your current data. This can include looking for duplicate entries, missing fields, inconsistent naming and so forth. You want to make sure that your data is as complete as it can be. Once you have done that, you can now design the structure of the data going into Unity Maintain.
As you build out and clean your data, you can build your data dictionary and data mapping rules for fields in your old data to fields into the new Unity Maintain data format. The data mapping rules contain the logic for answering questions like:
- What legacy data should be migrated?
- What Unity Maintain data object should it become?
- How should values be transformed?
- How should exceptions be handled?
- What is the minimum data quality threshold?
It may look something like this:
|
Legacy CMMS |
Unity Maintain |
Mapping Rule |
|
Asset Type = “HYD” |
Asset Category |
Convert HYD to “FireHydrant” |
|
Status = “A” |
Asset Status |
A = Active |
|
Status = “R” |
Asset Status |
R = Retired |
|
Install Year |
Install Date |
Convert year to Jan 1 of that year |
|
Work Priority 1-5 |
Priority |
1-2=High, 3=Medium, 4-5=Low |
3. Map, Clean & Transform
This is where we get to the technical heart of the migration process. As you have already created mapping rules in the previous step, you can now map the fields from old legacy data into your new Unity Maintain data format using the rules you have created. You can now apply that logic to mapping the data and converting it. This will allow you to clean and standardize your historical work data. You can also import templates or even prepare API payloads, if that is what you are using.
Your data mapping table may look something like this:
|
Legacy Table |
Legacy Field |
Unity Maintain Table |
Unity Maintain Field |
|
Report A Problem |
Problem ID |
Service Request |
Request ID |
|
Inspection |
Follow Up |
Inspection |
Resolution |
|
Workorders |
wo_dt |
Work Order |
Actual Finish Date |
|
Workorders |
wo_number |
Work Order |
Work Order ID |
This is where the physical mapping takes place via import scripts, ETL tools, API integrations or import templates that you may create.
The key take-away here is:
4. Test & Execute Migration
This is a vital step in your migration process. Ensure accuracy and minimize disruption by running a pilot migration for one site or area of your data. In this process you want to validate your work activities and other key data points in your data. Testing your migration first will dramatically reduce go-live issues.
Once you have tested the migration process, you will want to plan your cutover window and your data-freeze period with your internal stakeholders. This will ensure that you get all relevant data and that nothing is missed. When you start to run the migration, run it in structured batches, such as departments or data types, whichever applies to your organization.
After running each batch, check and reconcile record counts and resolve any exceptions that may arise from the process. Doing this after each batch run is key. If after running the first batch you realize something needs to be fixed, you will save yourself issues in every subsequent batch run. The earlier a problem is caught the less cost to solve it.
5. Stabilize, Train & Govern
Once the migration has been run, focus on adoption and long-term data health. This will consist of training field crews, technicians, clerical staff, supervisors and admins on your Unity Maintain workflows and data standards. Things like ensuring all work activities have an asset attached and that all required information is complete for those work activities. (This could be done via field validation in the Admin plugin of Unity Maintain.)
Now you can validate permissions and auto-generated work activities like Preventative Maintenance (PM) work orders. You can also establish ongoing data governance by setting up who can create and/or edit assets, admin permissions, work cycles and even create new codes in the system. Getting this part right will ensure your data stays clean going forward.
Lastly, you will need to monitor the system and gather user feedback on a continual basis and at prescribed checkpoints. It is also helpful to create specific data QA/QC dashboards that look for things like missing assets, locations or other necessary fields. Ultimately, you want to have a system that keeps your data clean, usable and valuable over the long term.
Following this methodology will greatly increase your chances of success with your data migration. Of course, our Public Works consultants are always here to help at Esri Canada. Just reach out to your account manager or to our Industry Manager, Christopher Roth for more information.