What to Expect During CMMS Implementation

You selected the CMMS.

Now the buying process turns into an implementation project.

The requirements you developed still matter. So do the workflows you demonstrated, the implementation assumptions in the proposal, the migration responsibilities, the integrations, the training plan and the tradeoffs you accepted.

Implementation is where those decisions become a working system.

The exact project will vary. A single-site organization replacing spreadsheets may have a much simpler implementation than a multi-site operation migrating years of asset and work history, connecting several systems and changing established processes. Public procurement records show why software price and the broader cost of putting a CMMS into operation can be different numbers, which we examine in What Does a CMMS Actually Cost?.

But most CMMS implementations have to answer the same basic questions:

• Who owns the project?
• How should the operation be configured in the system?
• What data should move?
• What data needs to be cleaned first?
• What systems need to connect?
• How will the configuration be tested?
• Who needs training?
• What has to be true before go-live?
• What happens immediately after go-live?
• Who will own the system after the implementation team leaves?

A useful implementation plan makes those questions explicit.

Start with the decision you already made

Do not begin implementation as though the buying process never happened.

Bring forward:

your requirements

workflow scenarios

evaluation notes

• implementation proposal
• assumptions and exclusions
• pricing scope
• integration commitments
• migration commitments
• accepted tradeoffs
• unresolved items
• contract and statement of work

These materials form part of the implementation baseline.

If an important workflow was demonstrated during selection, the implementation team should know what you saw.

If an integration was included in the proposal, identify who is responsible for delivering it.

If the decision depended on a particular mobile workflow, make sure that workflow appears in configuration and acceptance testing.

The implementation should preserve the reasons the system was selected.

Establish ownership before configuration starts

A CMMS implementation involves more than the vendor.

Depending on the organization, participants may include:

• maintenance leadership
• technicians
• planners or schedulers
• supervisors
• storeroom or inventory staff
• IT
• finance
• procurement
• security
• operations
• asset management
• implementation consultants
• software vendor personnel

Not everyone needs to attend every meeting.

But important decisions need owners.

At minimum, clarify:

Executive / business owner

Who can resolve priorities, resources and cross-functional issues?

Project lead

Who coordinates the implementation day to day?

CMMS owner / administrator

Who will own the system after go-live?

Workflow owners

Who can make decisions about how maintenance work should move through the system?

Data owners

Who can decide what data is authoritative and approve migrated data?

Integration owners

Who understands the systems being connected?

Test / acceptance owners

Who decides whether the configured system is ready?

Training owners

Who coordinates training and ongoing knowledge transfer?

The exact titles can vary.

The responsibilities cannot remain vague.

Map the implementation to the operation

Your requirements described what the CMMS needs to support.

Now those requirements have to become configuration.

That may include:

• sites and locations
• asset hierarchy
• asset classes
• work order types
• priorities
• statuses
• request workflows
• approval rules
• preventive maintenance
• inspection forms
• failure information
• labor tracking
• parts and inventory
• permissions
• notifications
• dashboards
• reports
• mobile workflows

This is where operational details become system decisions.

A status list that looks trivial on a configuration screen can affect how work is scheduled, reported and closed.

An asset hierarchy can affect navigation, reporting, PM assignment and history.

Required fields can improve data quality or create unnecessary technician burden.

Approval steps can provide control or slow routine work.

Use the operation as the reference point.

The objective is a configuration people can understand and maintain after the implementation team leaves.

Decide what data deserves to move

A new CMMS creates an understandable temptation:

Move everything.

Pause before doing that.

Your current information may be spread across:

• an old CMMS
• spreadsheets
• ERP records
• GIS
• inventory systems
• paper records
• shared drives
• individual files
• technician knowledge

The first migration question is not simply:

How do we import it?

Ask:

What information should exist in the new system, and which source should be trusted for it?

Possible migration areas include:

• assets
• locations
• asset hierarchy
• preventive maintenance schedules
• parts
• inventory balances
• vendors
• employees/users
• open work orders
• historical work
• meter readings
• documents
• failure information

For each area, determine:

• source
• owner
• condition
• required fields
• duplicates
• missing information
• mapping to the new system
• whether history is worth migrating
• validation method
• approval responsibility

A published Penn Medicine CMMS migration case described a process involving data assessment, data cleansing, migration planning, migration building, final migration and a period of dual maintenance.[2]

Your project may use a different sequence.

The important point is that migration includes decisions about data quality and ownership, not only file transfer.

Clean before you migrate where practical

Moving poor data into a new CMMS can preserve old problems in a new interface.

Look for issues such as:

• duplicate assets
• inconsistent asset names
• obsolete equipment
• incomplete locations
• conflicting IDs
• missing critical fields
• outdated PMs
• duplicate parts
• inconsistent units
• old users
• unreliable historical records

Do not turn data cleanup into an endless attempt to perfect every record before implementation.

Prioritize the data required to operate the system correctly at go-live.

Ask:

What has to be trustworthy on Day 1?

That may be a more useful target than:

Can we clean everything we have ever collected?

Build the asset hierarchy deliberately

The asset hierarchy deserves particular attention because many other CMMS functions depend on it.

A simplified structure might look something like:

Site → Building / Area → System → Asset → Component

Another operation may organize assets differently.

The right structure should reflect how your organization needs to:

• find assets
• assign work
• build PMs
• view history
• roll up costs
• report by location or system
• manage parent/child relationships

Avoid building hierarchy simply because the software allows another level.

The structure needs to remain understandable to the people using it.

If the hierarchy was part of your buying requirements, return to those requirements during configuration rather than inventing a new model in the implementation workshop.

Configure workflows before you automate them

A CMMS can formalize work that previously happened through calls, texts, paper, spreadsheets or memory.

Before automating a process, understand what should happen.

For a basic corrective workflow, for example:

1. A problem is identified.
2. A request or work order is created.
3. Priority is determined.
4. Work is assigned.
5. Technician receives the work.
6. Work is performed.
7. Labor, parts, notes or readings are recorded.
8. Follow-up work is identified if necessary.
9. Work is reviewed or closed.
10. History becomes available for future use.

Your process may differ.

The configuration should support the operation without adding steps simply because the software makes them possible.

Use the scenarios from your vendor demonstrations as test cases during configuration.

Treat preventive maintenance as its own workstream

Preventive maintenance data can require substantial decisions.

For each PM, you may need to establish:

• asset or asset class
• trigger
• frequency
• job plan
• tasks
• estimated labor
• required skills
• parts
• procedures
• safety information
• meter logic
• seasonal rules
• responsible team
• scheduling behavior

Review existing PMs before automatically importing them.

Ask:

• Is this PM still required?
• Is the frequency current?
• Is it assigned to the correct asset?
• Are the instructions useful?
• Does another PM duplicate it?
• Is the trigger calendar-based, meter-based or condition-based?
• Who owns future changes?

The goal is a usable preventive maintenance program in the new system, not merely a successful PM-record import.

Define integrations as data flows

An integration should be more specific than:

CMMS integrates with ERP.

For every important integration, identify:

What information moves?

Which direction does it move?

Which system is authoritative?

What triggers the exchange?

How often does it happen?

What happens when it fails?

Who monitors it?

Who supports it?

Possible integrations include:

• ERP / finance
• purchasing
• inventory
• GIS
• SCADA
• building automation
• HR / identity
• SSO
• IoT or condition monitoring
• reporting tools

Draw the flow if necessary.

A simple diagram showing System A → information → System B can expose assumptions that the word "integration" hides.

Use a test environment

Configuration should be tested somewhere that does not put active operations or production data at risk.

Use that environment for:

• configuration review
• migration tests
• integration tests
• workflow testing
• training preparation
• administrator practice
• user acceptance testing

A sandbox is useful because implementation involves iteration.

People need somewhere safe to discover that a workflow, permission, form or data mapping needs to change.

Test the work, not only the configuration

A field existing on a screen does not prove the process works.

Return to realistic scenarios.

For example:

Corrective work

• Request a repair.
• Set priority.
• Assign it.
• Receive it on mobile.
• Record labor and parts.
• Add a photo.
• Complete it.
• Find the history.

Preventive maintenance

• Trigger the PM.
• Generate the work.
• Schedule it.
• Complete it.
• Verify the next occurrence.

Inventory

• Issue a part.
• Change the balance.
• Trigger reorder logic if applicable.
• Correct an entry.

Supervisor

• Find overdue work.
• Reassign it.
• Review backlog.
• Identify repeat failures.

Integration

• Create or change the source data.
• Confirm that it reaches the destination.
• Test what happens when an error occurs.

User acceptance testing is an operational test

User acceptance testing — UAT — gives the people who understand the work an opportunity to determine whether the configured system can support it.

Do not limit UAT to the project team clicking through screens.

Include appropriate real users.

Give them realistic tasks.

Ask them to identify:

• missing information
• confusing steps
• unnecessary fields
• permission problems
• mobile problems
• terminology that does not match the operation
• reporting gaps
• workflow exceptions
• data problems

Track issues.

Assign owners.

Retest important fixes.

The objective is not to prove that the implementation team completed configuration.

The objective is to establish that the organization can use the system to do the work.

Train by role and workflow

A technician does not need the same training as a CMMS administrator.

A supervisor does not need the same training as a requester.

Consider separate training for:

• requesters
• technicians
• planners/schedulers
• supervisors
• inventory/storeroom users
• managers
• administrators

Teach the work people need to perform.

For a technician:

• receive assigned work
• find the asset
• review history
• record labor
• record parts
• enter readings
• attach a photo
• create follow-up work
• complete the work order
• work offline if applicable

For an administrator:

• manage users
• modify configuration
• maintain lookup values
• update workflows
• troubleshoot permissions
• manage templates
• support reporting
• maintain integrations or coordinate support
• understand release/update impacts

Training should help the organization operate after the consultants leave.

Decide what "ready for go-live" means

Do not let go-live become simply the date on the project schedule.

Create readiness criteria.

Depending on the project, those might include:

• critical workflows tested
• no unresolved critical defects
• required asset data loaded and validated
• required PMs loaded and validated
• integrations tested
• permissions tested
• mobile devices ready
• users created
• training completed
• support process established
• cutover plan approved
• backup / recovery responsibilities understood
• required documentation delivered
• open issues reviewed and accepted
• go-live support scheduled

Your criteria should reflect your project.

The important thing is to define readiness before the pressure of the go-live date makes the decision for you.

Plan the cutover

Cutover is the transition from the old way of working to the new one.

Clarify:

• when final data is extracted
• when final migration occurs
• whether old-system entry stops
• whether systems run in parallel
• how open work orders are handled
• how new requests are submitted during transition
• when integrations switch to production
• who validates production data
• who authorizes go-live
• how users get help
• what happens if a critical problem appears

For some organizations this may be simple.

For others it can require a detailed hour-by-hour plan.

Do not discover the cutover process on go-live morning.

Consider phased rollout where it reduces risk

You may not need to deploy every site, workflow, module or asset class at once.

A phased rollout can allow the team to:

• learn from early users
• correct configuration
• improve training
• clean additional data
• stabilize integrations
• reduce simultaneous change
• apply lessons to later groups

Indian River County's planned CMMS implementation uses phases, with one phase focused on horizontal assets and mobile/GIS workflows before expansion to vertical assets.[1]

Phasing is not automatically better.

It creates its own coordination and transition work.

Use it where the scope, risk or organization makes it useful.

Expect a stabilization period after go-live

Go-live is the beginning of production use.

Real work will expose things that testing did not.

Expect questions such as:

• Why can't I see this work order?
• Which status should I use?
• Why didn't this integration update?
• Where did this asset go?
• Why is this PM generating incorrectly?
• How do I correct this entry?
• Why doesn't this report match the old one?
• Who can change this field?
• Is this a training issue, configuration issue, data issue or software issue?

Plan for concentrated support after launch.

Track issues by category:

Data

Configuration

Integration

Software defect

Training

Process

Access / permissions

This helps prevent every problem from being labeled "the CMMS."

Protect the system from slow decay

After implementation, someone needs to own the CMMS.

Without ownership, small problems accumulate:

• duplicate assets
• obsolete users
• inconsistent statuses
• unused fields
• poor PM instructions
• broken reports
• unreviewed integrations
• stale lookup values
• workarounds outside the system
• declining data quality

Establish ongoing responsibilities for:

• user administration
• configuration
• data standards
• asset creation
• PM changes
• integration monitoring
• reporting
• release management
• training new employees
• issue escalation
• periodic workflow review

The implementation should leave the organization capable of running the system.

That is why documentation and knowledge transfer matter.

Measure whether the system is being used as intended

After stabilization, return to the reasons you bought the CMMS.

Possible questions include:

• Are technicians consistently completing work in the system?
• Is preventive maintenance being generated and completed correctly?
• Are asset histories becoming more useful?
• Are work requests entering through the intended process?
• Is required labor and parts information being captured?
• Are supervisors using the system to manage backlog?
• Are important integrations operating reliably?
• Are users returning to spreadsheets or side systems?
• Is the data becoming more trustworthy?

Choose measures that relate to the operational problems and goals identified before the purchase.

Do not measure success simply by whether the software is live.

A practical CMMS implementation checklist

Project setup

• Business owner identified
• Project lead identified
• CMMS owner / administrator identified
• Workflow owners identified
• Data owners identified
• Integration owners identified
• Project scope confirmed
• Roles and responsibilities documented
• Schedule and milestones documented
• Risks and communication process established
• Buying requirements and commitments carried into implementation

Configuration

• Sites and locations defined
• Asset hierarchy agreed
• Work types defined
• Priorities defined
• Statuses defined
• Request workflow configured
• Corrective workflow configured
• PM workflow configured
• Roles and permissions configured
• Mobile workflow configured
• Required forms/checklists configured
• Reports/dashboards defined

Data

• Data sources identified
• Authoritative sources identified
• Data owners assigned
• Required Day 1 data defined
• Duplicates reviewed
• Obsolete records reviewed
• Mapping documented
• Test migration completed
• Validation completed
• Final migration plan approved

Integrations

• Required integrations confirmed
• System of record identified for each data element
• Direction of data flow documented
• Triggers/frequency documented
• Error handling defined
• Support ownership defined
• Integration testing completed

Testing

• Test environment available
• Configuration tested
• Migration tested
• Integrations tested
• Critical workflows tested
• Mobile tested
• Offline workflow tested if required
• Permissions tested
• UAT completed
• Critical issues resolved or formally accepted

Training

• Training plan by role
• Technician training
• Supervisor training
• Planner/scheduler training if applicable
• Inventory training if applicable
• Administrator training
• Training materials delivered
• Internal support contacts identified
• Knowledge transfer completed

Go-live

• Readiness criteria defined
• Go-live checklist reviewed
• Cutover plan approved
• Final migration scheduled
• Production integrations ready
• Users/accounts ready
• Devices ready
• Support coverage scheduled
• Escalation process established
• Decision authority for go/no-go identified

After go-live

• Stabilization support active
• Issues categorized and tracked
• Critical issues prioritized
• User questions monitored
• Configuration adjusted where appropriate
• Data quality monitored
• Integrations monitored
• Adoption reviewed
• Ongoing system owner active
• Success measures reviewed against original goals

What should you know when implementation is complete?

Before closing the implementation project, you should be able to answer:

• Who owns the CMMS now?
• Can technicians complete the core workflows?
• Are required PMs operating correctly?
• Is the required asset data trustworthy?
• Are integrations operating and monitored?
• Can administrators maintain the configuration?
• Are users trained?
• Is documentation available?
• Are remaining issues known and assigned?
• Is there a process for future changes?
• Are you measuring whether the system is supporting the operational goals that justified the purchase?

A successful implementation leaves more than functioning software.

It leaves an organization that knows how the system is configured, trusts the information needed to operate it, can support its users, and can maintain the CMMS after the implementation project ends.