Data migration is where many EAM programs discover whether their operating model is real or only theoretical. It is one thing to agree on a target asset hierarchy, a preventive maintenance strategy, a work-order framework, and a spare-parts design in workshops. It is another thing entirely to move the underlying data into the new system in a way that allows planners, supervisors, technicians, and reliability engineers to trust it on day one. In asset-intensive environments, poor data is not a cosmetic problem. It disrupts maintenance execution, weakens safety controls, confuses storeroom transactions, and undermines confidence in the system before adoption has a chance to take hold.
This chapter focuses on the oversight disciplines that separate a credible migration from a technical data load. It begins with data strategy and standards, then turns to cleansing, enrichment, and normalization, which are usually far more demanding than organizations expect. It then addresses asset validation in the field, because no amount of spreadsheet work can substitute for confirming that the digital register matches physical reality. Finally, it covers migration rehearsal, reconciliation, and cutover controls, which determine whether the business can move into the new EAM environment without breaking maintenance continuity.
12.1 Data Strategy and Standards
A sound data strategy begins by rejecting a common but dangerous assumption: that migration is mainly a technical exercise of extracting legacy records, transforming them into the target format, and loading them into the new platform. In reality, migration is a business-design exercise with technical execution underneath it. The organization is deciding what data matters, which system owns it, what quality standard it must meet, how it will be governed after go-live, and what legacy inconsistencies will be corrected rather than carried forward. If those decisions are not made explicitly, migration becomes a transport mechanism for old problems.
The first strategic step is to define the data domains that the EAM program truly depends on. In most environments, these domains include the asset hierarchy, functional locations or sites, asset classifications, criticality, technical attributes, preventive-maintenance records, job plans, work-order history, failure codes, material masters and spare-parts links, open work, document references, and role or organizational data that determines responsibility. The exact scope varies, but the principle is the same. Each domain should have a clear answer to three questions. What is the object: what the data represents in business terms. What is the minimum live standard: the least information required for that object to function safely and effectively in the new environment. Who owns it: the business role accountable for its definition, quality, and ongoing maintenance.
System-of-record clarity is foundational. Asset and work-management teams often discover late in the program that multiple legacy systems, spreadsheets, engineering files, and local databases all claim authority over the same information. A pump may exist in the old CMMS, in an engineering register, in a maintenance spreadsheet, and in a financial asset list, all with slightly different descriptions or statuses. A data strategy should therefore identify the authoritative source: the source the business will trust when conflicts occur, and define how exceptions will be resolved. Sometimes there is a clear winner. More often, the new EAM register must be built by combining sources under business rules. Either way, the decision should be deliberate rather than left to the migration team to guess record by record.
Data standards then translate strategy into usable rules. Every serious EAM program needs conventions for naming, coding, hierarchy logic, classification, units of measure, criticality assignment, status values, failure taxonomy, and document linkage. These standards are not bureaucratic decoration. They are what make the data readable, comparable, and sustainable across sites and over time. A location or asset identifier should follow a pattern that users can understand. Descriptions should be specific enough to distinguish similar equipment. Status values should mean the same thing everywhere. Technical attributes should be consistent within an asset class so that reports and maintenance templates actually work. If a program avoids making these decisions because they are difficult, inconsistency will reappear immediately after go-live.
Quality dimensions should be defined early as well. Organizations often talk about data quality in vague terms, but migration teams need concrete tests. Completeness: required fields exist. Accuracy: the values reflect the real asset or material. Consistency: the same logic is used across the estate. Uniqueness: duplicate records are identified and controlled. Validity: the data conforms to the target rules and field structures. Usability: the information is sufficient for planning, execution, and analysis. A data set may pass basic load validation and still fail the usability test because technicians cannot identify the correct motor, planners cannot distinguish one seal kit from another, or reliability teams cannot compare failure history across similar assets. That is why the business must help define the standard, not just IT.
Another strategic question is how much legacy history should move. The instinct to bring everything is understandable. Maintenance leaders do not want to lose years of work-order history, inspection findings, and asset records. Yet full migration is not always practical or useful. The right answer usually depends on how the history will be used. Recent open work and active PM records almost always need structured migration. Core asset history that informs future planning, warranty, or compliance may deserve structured migration as well. Older history that is rarely queried may be better archived and linked rather than transformed in full. A disciplined data strategy distinguishes between operationally live data: information needed directly in the new system for current execution, and reference data: information that should remain accessible but does not need to be modeled completely in the target environment.
Minimum live standards deserve special attention because they prevent the program from loading records that are technically present but operationally weak. A maintainable asset should not go live with only a description and a legacy tag if the target operating model requires hierarchy position, class, criticality, status, responsible organization, and a minimum set of technical attributes. A spare part should not be considered ready for use if the material description is vague, the unit of measure is unclear, approved manufacturer information is missing where needed, or the storage logic has not been defined. Minimum live standards create a practical threshold for readiness and give the data team permission to hold back weak records rather than claiming volume success through incomplete migration.
Governance after go-live should be designed before migration begins. A common failure pattern is to build impressive data rules for the project phase and then dissolve the ownership model once the initial load is complete. The result is predictable. New assets are added inconsistently, PM templates drift, local terms creep into descriptions, and duplicate materials reappear. A mature strategy therefore assigns stewardship roles by domain, defines change-control pathways, and makes data quality part of business accountability rather than a one-time project activity. This is especially important for engineering handover, asset retirement, material-master changes, and criticality updates, all of which can damage reporting and planning if they are not governed.
Finally, the data strategy should be pragmatic about sequence. Not every field deserves the same attention at the same time. Critical assets, compliance-relevant records, active PMs, current stock items, and open work should usually receive the highest priority because weaknesses there will hurt immediately at go-live. Lower-value descriptive fields, low-risk historical detail, or legacy custom codes may be addressed later or archived. Prioritization is not a compromise in quality. It is an acknowledgement that the organization must protect the data that directly supports safe and effective maintenance continuity first.
12.2 Data Cleansing, Enrichment, and Normalization
If data strategy defines the target, cleansing and enrichment do the hard work of getting there. This is the stage where organizations discover how much ambiguity and inconsistency exists inside their current asset and maintenance records. The problems are familiar. Duplicate assets with slightly different names. Retired equipment still marked active. Preventive-maintenance plans assigned to the wrong hierarchy level. Material descriptions that are too vague to distinguish near-identical parts. Legacy codes that no one can fully explain. Missing criticality, missing technical attributes, incomplete failure history, and local site conventions that never aligned to an enterprise standard. Cleansing is the process of deciding what to correct, what to merge, what to enrich, what to discard, and what to archive.
The most important mindset is that cleansing is not a search-and-replace exercise. It is a business decision process supported by data analysis. Duplicate records, for example, cannot always be identified reliably through exact matching. One site may call a pump “P-101A,” another may have “Pump 101 A,” and a third may have an equipment description with no tag reference at all. Material duplicates are even more difficult because the same item may appear under different abbreviations, manufacturer references, or units of measure. Effective cleansing therefore combines automated rules with business review. Automated routines can highlight likely duplicates, missing fields, conflicting codes, and invalid values. Business owners then decide what should be merged, reclassified, enriched, or retired.
Asset cleansing typically begins with hierarchy rationalization. The team needs to identify assets that no longer exist, locations that are obsolete, records that should be combined, and areas where the current level of detail is either too shallow or too deep for the target model. This is not purely academic. If work history in the old system was recorded at a broad system level but the new design requires asset-level analysis, the program may need to enrich the structure or accept that some history will remain less granular. Conversely, if the legacy system contains excessive component-level detail that the business never uses, the team may decide to simplify and preserve the deeper information only as reference. Hierarchy cleansing is therefore closely tied to the target reporting and maintenance model.
Enrichment is where the company adds the information that legacy systems never captured reliably but the new operating model now requires. Criticality is a common example. Many organizations either lack it entirely or have an old rating model that no longer reflects business consequence. The migration program must then add or recalculate criticality for assets that need differentiated strategy. The same is true for technical attributes, class-specific fields, maintenance ownership, failure-code mapping, spare-parts links, and document references. Enrichment often takes more effort than cleansing because it requires external information sources and subject-matter judgment. A motor record with only a description may need power, voltage, speed, frame, location, and lubrication data before it becomes truly usable in the new environment.
Normalization ensures that data conforms to one enterprise logic rather than remaining a patchwork of local habits. This is especially important in multi-site organizations where each plant or facility historically used its own naming patterns, failure descriptions, and maintenance terms. Normalization does not mean stripping all local meaning from the data. It means translating local variations into a common structure so that the enterprise can report and govern consistently. A work type called “urgent repair” at one site and “priority corrective” at another may need to become one standard category. A family of material descriptions using different abbreviations may need to be rewritten under a common convention. A set of local criticality scales may need to be mapped into one enterprise model. Without normalization, the new EAM may look standardized in screen design while remaining analytically fragmented underneath.
Legacy preventive-maintenance data deserves especially careful cleansing. Companies often assume that if PM records exist, they can simply be migrated. In practice, legacy PM libraries usually contain duplicates, outdated vendor routines, generic tasks, incorrect intervals, inactive plans still marked live, and work plans that no longer match the physical asset. A good cleansing program distinguishes between migrate as-is: plans already aligned to the target strategy, migrate with correction: plans needing task, interval, or hierarchy adjustments, and rebuild: plans so weak or obsolete that migration would only perpetuate waste. This is one of the most value-rich parts of migration because poor PM data is one of the most common causes of early frustration after go-live.
Material-master cleansing follows a similar pattern. The team should identify duplicate items, obsolete stock, inconsistent units of measure, missing approved manufacturer references, broken catalog relationships, and materials that should be stocked differently under the new strategy. This work often uncovers surprising levels of duplication and ambiguity. Two records may describe the same gasket with different abbreviations, while a third record uses a vendor part number only. Without cleansing and normalization, planners will not trust the catalog and procurement will struggle to rationalize suppliers and contracts. Material quality is therefore just as important to migration success as asset quality.
Historical work data presents a different type of challenge. Work-order history can be valuable for reliability analysis, compliance evidence, and future planning, but it is usually the dirtiest part of the legacy environment. Free-text closure notes, inconsistent failure coding, and vague status usage make perfect cleanup unrealistic. The practical question is what level of normalization is worth the effort. Some programs choose to migrate only a limited period of structured history and archive the rest. Others map the most important fields, such as asset reference, date, work type, and cost, while leaving narrative detail as legacy reference. The right answer depends on how much the business truly needs historical comparability inside the live system versus access to older records outside it.
Cleansing programs often underestimate the volume of exception handling required. There will be records with conflicting source values, materials with incomplete manufacturer data, assets with unclear active status, PMs with no obvious owner, and legacy codes whose original meaning has been lost. The right response is not to delay endlessly until every case is perfect. It is to define decision rules and escalation paths. A data council or design authority should decide how to handle unresolved exceptions, what criteria justify exclusion from go-live, and which enrichments can be completed later without harming operations. This keeps the cleansing effort moving while preserving control over quality.
Perhaps the most important oversight principle is that cleansing should be visible and measurable. The program should know how many records were assessed, how many were enriched, how many duplicates were merged, how many PMs were rebuilt, how many materials were normalized, and how many exceptions remain open by criticality and domain. Progress measured only by records loaded is misleading. A cleaner measure is readiness by business usability. Can the planner find the right asset? Can the technician identify the right material? Can the PM library generate work that matches the current operating model. Those are the real tests that cleansing and enrichment must ultimately satisfy.
12.3 Asset Validation in the Field
No matter how carefully the data is reviewed in spreadsheets, databases, and workshop sessions, the ultimate test of an asset register is whether it matches the physical world. Field validation is the discipline of confirming that the assets, locations, tags, statuses, attributes, and relationships in the target EAM reflect what actually exists in plants, buildings, networks, fleets, or facilities. This is one of the most underestimated parts of an EAM program because it is labor-intensive, operationally disruptive if poorly planned, and often exposes uncomfortable truths about how incomplete the legacy record really is. Yet it is also one of the highest-value activities in the whole program because it is the point where digital design meets operational reality.
The purpose of field validation is broader than checking whether an asset tag exists. The team should confirm at least five things. Existence: the asset or location physically exists and is relevant to the operating model. Identity: the tag, serial, description, or other identifiers are correct enough to distinguish it from similar equipment. Hierarchy position: the asset sits in the right functional or location context. Status: the asset is active, inactive, spare, removed, or retired as the record indicates. Maintainability: the asset should indeed be managed as a separate maintainable item in EAM rather than as part of a higher-level assembly. These checks are what prevent ghost assets, orphaned PM plans, and planning errors after go-live.
Validation scope should be risk-based. It is rarely practical to walk every record in large and complex estates at the same depth. Critical assets, compliance-relevant equipment, bottleneck production assets, safety systems, active storeroom-linked assets, and areas with known legacy-data weakness usually deserve full validation. Lower-risk equipment may be validated through sampling, targeted spot checks, or desk review supported by local confirmation. The oversight principle is simple: the more damaging it would be to have the wrong data at go-live, the more direct the validation should be. Programs that try to validate everything equally often run out of time and end up validating the important assets too shallowly.
Field validation should be carefully organized rather than treated as an ad hoc site exercise. The team needs defined check sheets or mobile data-capture methods, clear decision rules for discrepancies, trained validators who understand both the physical environment and the target data model, and a mechanism for recording and resolving issues without losing traceability. In many organizations, the strongest validation teams pair local operational knowledge with project or reliability discipline. The local technician or supervisor knows the equipment and can spot practical problems quickly. The project validator understands the hierarchy rules, classification standards, and minimum data requirements. That combination produces better results than either role working alone.
The walkdown itself should confirm not only tags and existence, but also physical relationships that matter to maintenance. Is the motor actually associated with the pump record the hierarchy shows. Does the standby unit exist and have the right status. Are there duplicate tags in the area that could confuse work execution. Is the document reference visible and current where needed. Does the field equipment indicate attributes or nameplate data missing from the record. Are there assets in service that never made it into the legacy system at all? These discoveries are common, especially in older facilities where modifications and replacements were executed over years without disciplined data update.
Validation is also where asset lifecycle truth becomes visible. Programs often find equipment that was retired years ago but never removed from the system, or recently installed equipment still missing from the register, or temporary assets that became effectively permanent. These are not minor data irritations. Retired assets can continue generating PMs, confuse planners, and inflate inventory associations. Missing active assets can leave the maintenance team with no trustworthy history or PM coverage. Temporary modifications left undocumented can create serious safety and compliance exposure. Field validation should therefore be empowered to recommend status changes, record creation, retirement, and follow-up engineering review where necessary.
Photographic evidence and nameplate capture can add substantial value when used selectively. For critical assets or where identification is ambiguous, a photo tied to the validation record can help planners and future technicians confirm they are dealing with the right equipment. Nameplate photos can be especially useful for enriching technical attributes and verifying manufacturer data. The goal is not to create a photo archive for every low-risk asset. It is to use visual evidence where it materially improves confidence, supports enrichment, or resolves ambiguity that legacy records left behind.
Field validation must also handle disagreement. Sometimes the field says the spreadsheet is wrong. Sometimes the spreadsheet reflects an engineering intent that the field has informally bypassed. Sometimes neither is clearly correct. These cases require a disciplined resolution pathway. Validators should capture the discrepancy, classify its impact, assign an owner, and avoid silent local fixes that undermine data governance. A motor that appears installed in a different service than expected may require engineering confirmation before the hierarchy is changed. A safety-critical asset with unclear identification may require urgent remediation before go-live. A retired piece of equipment still shown as active may simply need confirmation and update. The key is to make the discrepancy visible, triaged, and resolved deliberately.
Site leadership support is crucial because field validation competes directly with normal operations. It requires access, escorts, knowledgeable personnel, and sometimes temporary disruption of routine work. Without strong local sponsorship, validation is pushed aside in favor of daily firefighting and the program receives only partial confirmation. This is one reason executive governance matters. Site leaders need to understand that field validation is not project administration. It is essential risk control for the new maintenance system.
Another often overlooked issue is validation of maintainability boundaries. Legacy systems frequently contain assets at inconsistent levels of granularity. A field walkdown may show that several records representing small subcomponents are not actually maintained separately and should be combined, while a larger assembly may need to be decomposed because technicians routinely replace or analyze a specific subasset independently. These decisions affect planning, cost visibility, and reliability analysis, which is why field validation is often the best place to correct them. The physical reality of how work is executed is much easier to assess next to the asset than in a conference room.
The strongest field-validation programs end with explicit sign-off by domain or area. That sign-off should state what was validated, what remains unresolved, what exclusions or assumptions apply, and who accepts the residual risk. It should not be a vague acknowledgment that a site “reviewed the data.” Clear sign-off creates accountability and gives the migration team a defensible basis for deciding whether an area is ready for load and go-live. It also provides a record for later waves so the organization can learn how much validation effort different asset types really require.
12.4 Migration Rehearsal, Reconciliation, and Cutover Data Controls
Even strong data strategy, cleansing, and field validation can still fail at the last moment if migration execution and cutover controls are weak. The reason is straightforward. An EAM cutover is not only about loading master data into a new system. It is about preserving maintenance continuity while moving active operational records, open work orders, due preventive tasks, inventory balances, reservations, asset history, user access, and document links into a live environment that people will rely on immediately. That transition is too consequential to be attempted only once. It needs rehearsal, reconciliation, and decision gates based on evidence.
Migration rehearsal serves two purposes. First: it tests the technical load process, transformation rules, sequencing, and performance of the migration routines. Second: it tests whether the business can live with the resulting data in a realistic environment. Many programs focus heavily on the first and underinvest in the second. A rehearsal that loads successfully but leaves open work attached to the wrong assets, due PMs triggered incorrectly, stock balances mismatched, or history inaccessible is not a successful rehearsal. It is a technical proof that the business still cannot operate from the result.
Rehearsals should therefore be full enough to expose real cutover risk. At minimum, the program should prove that asset and location structures load correctly, critical classifications and attributes are present, PM programs generate as expected, active and open work migrates with the right status and references, inventory and reservation data reconcile, required users and roles can transact, and essential documents or links are available. Where integrations are part of day-one operations, the rehearsal should test those too. The right question is not “did the migration script run.” It is “could a planner, supervisor, technician, and storeroom lead run a normal maintenance cycle from this result.”
Sequencing is one of the most important cutover design choices. Assets usually need to load before PMs and work orders. Materials and storeroom structures need to exist before inventory balances and reservations can make sense. User roles and security should be ready before business testing begins. Open work may require transformation rules depending on status, such as whether partially completed jobs move as open work, closed history, or both. These dependencies need explicit design and repeated rehearsal. If sequencing is improvised late, errors cascade quickly and are difficult to untangle under cutover pressure.
Reconciliation is the discipline that turns rehearsal output into trust. The program should compare source and target volumes, but that is only the beginning. Count matching alone proves very little if records were transformed incorrectly or loaded to the wrong objects. Reconciliation should therefore include structural, transactional, and business-use tests. Structural reconciliation: do the expected number of assets, locations, PMs, materials, and users exist in the correct categories. Transactional reconciliation: do open work, inventory balances, reservations, and status mappings align. Business-use reconciliation: can the business perform critical scenarios, such as planning a job, issuing a part, closing a PM, and retrieving recent history. The more critical the domain, the more reconciliation should focus on usability rather than on volume statistics alone.
Open-work handling is one of the highest-risk areas in cutover. The program needs clear rules for which work orders migrate, which are closed in the legacy system before cutover, which become follow-up notifications, and how partially completed work is treated. A job waiting on a shutdown window is different from an emergency repair in progress. A PM due tomorrow is different from a historical work order closed three years ago. Without explicit business rules, cutover teams either migrate too much noise or lose work that the field still needs. These rules should be tested with real site examples during rehearsal, not invented during the final weekend.
Inventory reconciliation can be equally unforgiving. Storeroom balances, bin locations, lots or serials where relevant, staged kits, reservations, repairables under repair, and items in transit all create potential mismatch between source and target. A successful cutover requires a freeze strategy and count logic that the business understands. If physical transactions continue in uncontrolled ways during the transition window, no amount of technical precision will save the balances from drifting. This is why cutover planning must integrate storeroom operations, procurement, and maintenance scheduling rather than treating inventory as a background data extract.
Cutover controls should include a clearly defined freeze period, decision checkpoints, contingency plans, and named owners for each critical domain. The freeze period does not have to mean the business stops all maintenance work. It means there is controlled treatment of what can still change in the source systems, who can authorize it, how it will be reflected in the final delta load, and what manual bridging may be required. Decision checkpoints should confirm whether rehearsed issues are closed, whether defect levels are acceptable, whether reconciliation has passed, and whether site leadership is prepared operationally. If these controls are vague, the final cutover becomes a heroic effort dependent on individuals rather than a managed business transition.
Delta migration deserves careful attention as well. Even after a successful rehearsal, the production cutover must account for what changed between the last rehearsal snapshot and the final go-live load. New work orders were created, parts were issued, assets changed status, PMs became due, and documents were added or revised. The program needs clear logic for capturing and loading these deltas without duplicating or losing transactions. This is often where rehearsals expose hidden complexity, especially when legacy systems were never designed for clean extraction under high transaction volume. Better to discover that during rehearsal than during the final cutover window.
Post-load validation should happen immediately after the production migration, before the system is fully handed to the business. This validation is not as extensive as full field verification, but it should confirm that the critical reconciliation points, user access, PM generation, open work, stock balances, and key integrations behave as expected in the production environment. Early defects can then be triaged within the cutover team before they become site-level confidence problems. Hypercare is not a substitute for post-load validation. Hypercare supports the live business after release; post-load validation confirms the release itself is sound enough to begin.
The final oversight principle is disciplined go or no-go criteria. Programs often know, in private, that certain data issues remain unresolved but rationalize them as problems that can be fixed after launch. Sometimes that is reasonable. Sometimes it is reckless. The difference depends on business impact. Incomplete descriptions on low-risk historical records may be tolerable. Unvalidated critical assets, broken reservations for scheduled work, incorrect PM generation for compliance tasks, or missing hierarchy relationships for major production equipment usually are not. Go-live criteria should therefore distinguish between deferrable defects: issues that can be safely corrected after launch with agreed ownership, and blocking defects: issues that threaten safe, compliant, or continuous operations. That distinction protects the business from the very human tendency to confuse schedule pressure with readiness.
When migration rehearsal, reconciliation, and cutover controls are handled rigorously, the organization enters go-live with something more valuable than clean data. It enters with justified confidence that the new EAM environment can support real maintenance work without leaving the field to repair the project’s assumptions after launch.
