Steel Plant CMMS Data Migration Audit Checklist

CMMS data migration—moving maintenance records, asset data, and preventive maintenance schedules from a legacy system to a new platform—is treated by most steel mills as a technical IT task: export data, import data, go live. In reality, a failed CMMS migration introduces operational chaos: $50K+ equipment shown in the new system with no preventive maintenance scheduled, critical assets missing from the asset register, work order history dating back 5 years lost (breaking compliance documentation), spare parts inventory mismatched to assets (orders placed for parts that fit different equipment models), and preventive maintenance schedules with wrong frequencies (annual inspections become monthly, creating alert fatigue). Steel mills with documented CMMS data audits before migration catch these gaps 30-60 days before go-live, allowing correction time. Mills that skip the audit discover issues post-go-live when maintenance is already attempting to work in the new system, causing production delays and safety gaps. A comprehensive pre-migration audit verifies: asset hierarchy completeness, asset naming consistency, bill-of-materials accuracy, spare parts inventory validity, preventive maintenance schedule correctness, and work order history preservation. Oxmaint's CMMS migration audit module guides teams through systematic data validation, identifies duplicates and orphaned records, and generates a migration readiness report proving data quality before cut-over.

Execute Risk-Free CMMS Migration with Data Audit Asset hierarchy validation, BOM accuracy checks, spare parts inventory reconciliation, PM schedule verification, and work order preservation—migration readiness assurance.

Start Free Trial Book a Demo

1. Asset Hierarchy Structure & Nomenclature Audit

Asset hierarchy defines how equipment is organized: Site → Building → Floor → Area → Equipment → Sub-Component. A well-designed hierarchy makes asset identification fast and reporting intuitive; a poorly designed one creates confusion ("Is the furnace backup pump in the 'Cooling' group or the 'Auxiliary' group?"). Before migration, audit the legacy system's asset structure and establish a standardized hierarchy for the new system. Inconsistent asset names ("Pump 1", "Pump-001", "PUMP#1", "Main circulation pump") cause the same asset to appear multiple times in reports, creating phantom duplicates. Systematic renaming—establishing naming conventions and applying them consistently—is tedious pre-migration work but essential for post-migration accuracy.

Define Target Asset Hierarchy & Establish Location Classification Structure Design the new CMMS hierarchy: (1) Level 1 (Site): "USA-TX-SteelMill-1"; (2) Level 2 (Building): "Melt Shop", "Rolling Mill", "Support Services"; (3) Level 3 (Area/Zone): "Furnace Bay 1", "Electric Arc Furnace Deck", "Cooling Water Plant"; (4) Level 4 (Equipment): "Furnace Refractory", "Transformer 480V-1", "Cooling Tower Pump". Each level should be clearly defined with naming rules: equipment names should include the asset type (Pump, Motor, Valve), location, and sequence if multiple exist (not just "Pump 1" but "Furnace Cooling Pump-1"). Document the hierarchy structure in a template and establish a hierarchy steward (typically the maintenance planning manager) who reviews new assets for compliance. In Oxmaint, enforce hierarchy structure with drop-down lists (Location → Building → Area) preventing ad-hoc naming that creates inconsistency.

Audit Legacy Asset Names & Consolidate Duplicates & Near-Duplicates Export the legacy system's asset list and search for duplicates: same equipment with different spellings ("Cooling Tower" vs "Cooling Twr" vs "CT-1"), duplicate serial numbers (indicating the asset was created twice in the legacy system), and orphaned assets (equipment decommissioned years ago but never marked inactive). Remove obvious duplicates (keep the most-detailed record). For near-duplicates, investigate: is it truly the same equipment or two similar assets? Use the serial number as the authoritative identifier—if serial numbers match, it is a duplicate; if different, it is a separate asset. Consolidate work order history from duplicates into a single asset record before migration. Example: "Cooling Tower #1" and "Cooling Tower-1" are the same asset (serial: CT-001)—merge their work order history into the primary record and delete the duplicate before migration. In Oxmaint, create a duplicate detection report and require technician review of potential matches before consolidation.

Verify Equipment Serial Numbers & Manufacturer Data Accuracy For critical assets (pumps, motors, valves, sensors), verify the recorded serial number matches the physical equipment nameplate. Walk the facility with the legacy asset list and spot-check 20% of assets (random selection across all equipment types). Corrections needed: update mismatched serial numbers, add missing serial numbers from physical inspection, correct manufacturer names (is it "Dunn and Porter" or "Dunne & Porter"?), verify model numbers match the actual equipment. Missing or inaccurate serial numbers break the ability to link equipment to manufacturer documentation, spare parts catalogs, and technical bulletins. In Oxmaint, flag assets with blank serial numbers and prevent migration until serial numbers are populated. Create a pre-migration data-cleaning project where field technicians visit assets to confirm serial numbers on-site.

Assign Criticality Ratings & Equipment Categorization Consistently Every asset should have a criticality rating: (1) Critical (failure causes production stoppage or safety hazard); (2) Important (failure causes delays or quality issues); (3) Standard (failure is manageable, can be repaired with minor disruption). Categorize each asset by type (Pump, Motor, Compressor, Valve, etc.) using a standardized taxonomy—do not allow ad-hoc descriptions like "Misc Equipment". Criticality and categorization determine PM strategy: critical equipment gets more frequent PM and tighter monitoring, standard equipment gets basic maintenance. Inconsistent categorization leads to under-maintained critical equipment or over-maintained standard equipment. In Oxmaint, create a categorization drop-down list and require criticality assignment for all assets before migration. Use criticality to auto-suggest PM frequencies (critical equipment → monthly or quarterly PM; standard → semi-annual or annual PM).

2. Bill of Materials (BOM) & Spare Parts Inventory Validation

A bill of materials (BOM) lists components that comprise a complex asset: a furnace cooling system consists of pump, motor, coupling, impeller, housing, shaft, bearings, seals, gaskets. Spare parts inventory is linked to BOM items—when a pump bearing fails, the spare parts module shows "Bearing, Pump ABC Model XYZ, qty 2 on hand". If the BOM is incomplete (missing the bearing), spare parts planning becomes guesswork. If spare parts quantities are wrong (showing 5 units when only 2 are physically in inventory), ordering decisions are flawed. Pre-migration BOM and spare parts audit prevents post-migration surprises: "We thought we had spare bearings; turns out we don't" is discovered during preventive maintenance, not after the bearing fails.

Audit BOM Completeness Against OEM Manuals & Technical Specs For each critical asset, retrieve the OEM manual and verify the BOM captures all major components: for a centrifugal pump, the BOM should include pump housing, impeller, shaft, mechanical seal, coupling, wear rings, gaskets, and fasteners. Compare the legacy system's BOM against the OEM manual. Gaps indicate the legacy BOM was incomplete or simplified. Add missing components to the BOM before migration. If a component appears frequently in service records (high failure rate) but is missing from the BOM, add it. Example: furnace refractory lining—the BOM should list refractory material specifications and campaign replacement criteria. In Oxmaint, link each asset's BOM to its OEM documentation and require BOM completeness verification before migrating the asset.

Validate Spare Parts Inventory Quantities Against Physical Count Do not trust legacy inventory counts without verification. Conduct a physical inventory count of spare parts: visit the storeroom, count every item listed in the spare parts inventory, and compare to the system quantity. Discrepancies are common: "System shows 8 pump impellers; actual count is 3" (4 were used in maintenance and removed from inventory without system update, 1 was damaged and discarded). For each discrepancy, correct the system quantity to match physical count. If a critical spare part is missing or below minimum stock (e.g., only 1 bearing on hand for a pump that fails every 2 years), flag for procurement before migration. In Oxmaint, generate a reconciliation report comparing system inventory to physical count. Do not migrate spare parts until this reconciliation is completed—post-migration inventory errors break preventive maintenance planning.

Link Spare Parts to BOM Components & Verify Vendor/Manufacturer Information Each spare part should be linked to a BOM component (so when you search "Pump ABC impeller", the system shows you the part number, vendor, and current inventory). Verify vendor information: is the current vendor still the preferred source, or has the facility switched vendors? Are alternate suppliers documented (if the primary supplier is unavailable, can we substitute with an alternate part)? For critical spare parts, maintain a vendor comparison: primary vendor, alternate vendor, cost difference, lead time. Example: furnace refractory—primary vendor "Refracto Corp", alternate vendor "HeatResist Inc" with 15% price premium but 1-day faster shipping. In Oxmaint, create a spare parts module that displays BOM component name, spare part number, vendor, quantity on hand, reorder point, and lead time. Use this data to auto-trigger purchase orders when inventory falls below reorder point.

Identify Obsolete & Decommissioned Equipment & Archive Before Migration The legacy system likely contains equipment decommissioned years ago (old furnace no longer in use, pump replaced with a newer model, etc.). These assets should not be migrated to the active CMMS—they create clutter and confusion. Identify decommissioned assets: (1) no work orders in the past 3 years, (2) explicitly marked as inactive/obsolete, (3) equipment physically removed from service. Archive these records (export to a separate "historical" file) and exclude from the new CMMS. If you migrate obsolete assets, preventive maintenance schedules will try to generate work orders for equipment that no longer exists. In Oxmaint, mark assets as "Archived" rather than deleting them (you may need them for historical investigation), but exclude archived assets from active PM scheduling and reporting.

3. Preventive Maintenance Schedule Accuracy & Work Order History Validation

Preventive maintenance is the heart of a functional CMMS. A PM schedule specifies: which equipment requires maintenance, what type (inspection, lubrication, part replacement), how often (monthly, quarterly, annually), and what procedure to follow. If a PM schedule fails to migrate correctly (frequency changes from monthly to quarterly, or procedure steps are lost), real equipment will miss scheduled service without any alert to the maintenance team. Work order history (completed maintenance records) is compliance documentation—OSHA auditors request 3-5 years of work order history to verify preventive maintenance was actually performed. Lost or incomplete work order history is a serious audit gap.

Audit PM Schedules Against OEM Recommendations & Equipment Criticality Retrieve OEM manuals for major equipment and compare recommended PM intervals to the legacy system's PM schedules. Discrepancies indicate either the legacy PM was outdated or intentionally modified. Examples: OEM recommends annual pressure relief valve testing; legacy system shows "as needed" (risky—testing may be skipped). OEM recommends monthly bearing lubrication; legacy system shows quarterly (premature bearing wear expected). For critical equipment, PM intervals should match OEM recommendations. For standard equipment, longer intervals may be acceptable if historical failure data supports them. Create a PM validation matrix: equipment name, OEM recommended frequency, current frequency, and decision (keep / change). Propose PM frequency changes for equipment exceeding failure thresholds. In Oxmaint, auto-populate PM templates from OEM data when available; require PM frequency review before migration.

Verify PM Procedure Steps Complete & Assign Responsible Trade/Skill Each PM schedule should reference a detailed procedure: "Furnace pump bearing inspection" procedure should include: (1) stop the pump, (2) listen for bearing noise (if noise, schedule bearing replacement), (3) check alignment using dial indicator, (4) verify bearing temperature (do not exceed 80°C during operation), (5) log findings in work order. Legacy systems often lack detailed procedures—steps are missing or vague. Before migration, develop detailed PM procedures for critical equipment. Assign each PM to a responsible skill/trade: "Pump bearing inspection" is assigned to "Mechanical Technician"; "Electrical motor testing" is assigned to "Electrical Technician". This ensures the right person is scheduled for each PM, improving quality and reducing rework. In Oxmaint, create a PM procedure library and link each PM schedule to its procedure. If a procedure is missing, flag the asset as "non-migratable until procedure is written".

Preserve Work Order History & Validate Completeness Before Migration Export 3-5 years of work order history from the legacy system. Verify that key fields are populated: (1) Asset ID (which equipment was maintained); (2) Work order date (when was it completed); (3) Work order type (PM / Corrective / Inspection); (4) Technician name (who did the work); (5) Labor hours and cost; (6) Description (what was done); (7) Parts used (spare parts consumed). Missing data in any of these fields weakens the historical record. Example: work orders with missing asset ID cannot be linked to equipment history. Work orders with no technician signature cannot be used for compliance documentation. Clean the data before migration: add missing asset IDs, add missing technician names (if archived, use "Unknown" rather than leaving blank), add narrative descriptions if only a work order number exists. Keep the historical data—it is audit gold and cannot be regenerated. In Oxmaint, migrate work orders as read-only historical records (technicians cannot modify them post-migration); they become an immutable audit trail.

Test PM Schedule Generation & Validate First Month Post-Go-Live Before migration is finalized, conduct a test: configure PM schedules in the new system and ask it to generate work orders for the next 30 days. Review the output: are the correct assets receiving PMs, are frequencies correct (not too frequent or too sparse), are procedures linked, are responsible technicians assigned? Identify any anomalies (missing assets getting no PM, assets getting excessive PM frequency) and correct before go-live. Plan for the first month post-go-live with heightened attention: monitor PM work order generation daily, verify that technicians are receiving assignments, and track completion. The first month is when data migration errors surface—an asset might not receive scheduled PM because it was not migrated, or a PM frequency might be wrong, causing excessive work orders. In Oxmaint, generate a "Migration Go-Live Report" showing all active assets with assigned PM schedules, allowing a final spot-check before cut-over.

4. Data Cleansing & Go-Live Readiness Verification

Data migration is not just exporting and importing—it is systematic data cleaning, validation, and testing. A robust migration includes multiple validation passes, stakeholder review, and a formal readiness sign-off before go-live. Post-go-live surprises (missing assets, orphaned spare parts, broken PM schedules) are disruptive and erode confidence in the new system. Pre-go-live diligence ensures smooth transition and rapid adoption.

Conduct Data Migration Dry Run & Reconciliation Against Legacy System Perform a test migration (copy of the data migrated to a test environment, not production). Verify: (1) Record count—are the number of assets, PMs, spare parts, and work orders in the new system equal to the legacy system (minus intentionally archived records)? (2) Data accuracy—spot-check 10% of assets for correct nameplate data, PM schedules, and work order history. (3) Referential integrity—is every PM linked to a valid asset, is every spare part linked to a valid BOM component? Identify discrepancies (missing records, mismatches) and resolve before the final migration. Create a reconciliation report comparing legacy data to migrated data. This report is your safety net—it documents what you expected to migrate and what you actually migrated. In Oxmaint, auto-generate reconciliation reports and require stakeholder sign-off confirming data matches expectations.

Identify & Flag Data Gaps & Create Remediation Plan for Missing Items No migration is 100% complete—gaps are inevitable. Typical gaps: assets with no PM assigned (especially critical equipment), spare parts orphaned from BOM components, work order history with missing asset links. Create a gap report listing every deficiency and a remediation plan: (1) Critical gaps (missing PM for critical equipment)—assign owner and due date to add PM before go-live; (2) Important gaps (spare parts without BOM links)—assign owner to reconcile and link; (3) Minor gaps (cosmetic data like missing phone numbers)—schedule for post-go-live correction. Set a deadline: all critical gaps must be remedied 2 weeks before go-live, allowing a final validation pass. In Oxmaint, create a gap tracking system and require closure evidence (completed PM, linked spare part, updated asset) before closing each gap item.

Obtain Stakeholder Sign-Off & Document Go-Live Authorization Before migration is finalized, require explicit approval from: (1) Maintenance Manager (the people who will work in the system daily); (2) Operations Leader (who will request maintenance through the system); (3) Finance/Procurement (who will manage spare parts inventory); (4) IT (who will support the system post-go-live). Each stakeholder reviews the migration readiness report and reconciliation. Concerns are escalated and addressed before sign-off. Once all stakeholders approve, the migration is authorized. Create a go-live sign-off document listing stakeholders, their approval date, and any conditions or concerns noted. If a stakeholder does not approve (e.g., "We have concerns about PM frequency accuracy"), the migration is delayed until the concern is resolved. In Oxmaint, collect electronic sign-offs in the migration project record—this documents that the facility followed a structured, reviewed migration process, not a hasty cut-over.

Plan Post-Go-Live Monitoring & Establish Support Protocol for Issues The first week post-go-live is critical. Assign: (1) Data owner (person responsible for investigating data issues if they surface); (2) CMMS administrator (managing user access, permissions, technical issues); (3) Escalation path (who do users contact if something is wrong). Establish daily check-ins during the first week: are technicians able to access their work orders, are PMs generating as expected, are spare parts orders flowing correctly? Log any issues and triage: (1) Critical (system is down, technicians cannot work)—fix immediately, possibly escalate to vendor support; (2) High (data is missing or incorrect, but system is functioning)—resolve within 24 hours; (3) Medium (minor functionality gaps)—schedule for within 1 week; (4) Low (cosmetic issues)—schedule for later. In Oxmaint, establish a post-go-live support dashboard showing status of all systems, upcoming actions, and issue log—this becomes the communication hub for the first 30 days.

Ensure CMMS Migration Success Through Pre-Migration Audit Asset hierarchy validation, BOM completeness, spare parts reconciliation, PM schedule verification, work order history preservation, and go-live readiness sign-off.

Start Free Trial Book a Demo

CMMS Data Migration — Frequently Asked Questions

1. Why is data migration so risky if it seems like a simple export-import?

Legacy systems may have incomplete data, duplicate records, inconsistent naming, and broken relationships (spare parts not linked to assets). A direct export-import preserves these problems. Pre-migration audit identifies and fixes these issues before data is loaded into the new system.

2. What is the most critical data to verify before migration?

Asset hierarchy and master equipment records are foundational—if these are wrong, everything downstream fails. Preventive maintenance schedules are second-most critical—missed PM schedules leave equipment unmaintained. Work order history is third—compliance documentation depends on its completeness.

3. How many duplicates are typical in legacy asset databases?

Depending on system age and discipline, 5-15% of assets may be duplicates or near-duplicates. A 500-asset database might have 25-75 duplicate records. These should all be consolidated before migration to prevent phantom assets in the new system.

4. Should obsolete/decommissioned equipment be migrated to the new CMMS?

No. Archive obsolete equipment records separately (for historical traceability) but exclude them from active CMMS. Migrating obsolete equipment creates clutter and confuses technicians. PM schedules will attempt to generate work orders for equipment that no longer exists.

5. What happens if PM schedules are wrong after migration?

If a PM frequency is wrong (annual instead of quarterly), the equipment will be under-maintained without any system alert. This can lead to accelerated equipment failure and maintenance surprises. Validate PM frequencies against OEM recommendations before migration.

6. How should work order history be handled during migration?

Preserve the last 3-5 years of work order history as read-only records for compliance documentation. Older history can be archived. Ensure work orders are linked to valid assets so they contribute to equipment maintenance history, not orphaned records.

7. What is a data reconciliation report and why is it important?

A reconciliation report compares record counts and sample data from the legacy system to the new system, verifying that migration was complete and accurate. It provides evidence that the migration was systematic and reviewed, not a hasty cut-over.

8. How much time should be allocated for pre-migration audit and data cleaning?

Typically 6-12 weeks depending on database size and data quality. A 500-asset database with poor data discipline may require 12 weeks of systematic cleaning. A well-maintained database may require only 6 weeks. Plan conservatively—rushing data migration is a false economy.

Execute Flawless CMMS Migration with Comprehensive Data Audit Asset validation, hierarchy standardization, BOM verification, spare parts reconciliation, PM schedule testing, and stakeholder sign-off—migration certainty.

Start Free Trial Book a Demo