Migrating CMMS and EAM to the Cloud

Almost every cloud migration conversation I get pulled into starts in the wrong place. Someone has seen a demo of a modern maintenance platform, the on-premise system is two or three versions behind, the server it runs on is out of warranty, and the assumption in the room is that the answer is to replace the product. Sometimes that is right. More often the cheaper, lower risk move is to take the same product to the vendor's own cloud edition, keep the configuration and the muscle memory, and spend the saved effort on the asset register instead. The point of this guide is to slow that decision down long enough to make it properly, then to be honest about the work that follows once it is made.

The message up front: the route you choose matters more than the platform you choose, customisations are the dominant cost and risk, the interfaces to ERP and to building or plant control systems are the hardest technical work, and data cleanup is the task that decides whether you hit your date. A migration is also the only realistic chance you will get for years to fix the asset register. Not taking that chance is expensive, and the cost lands quietly, in every report that comes out wrong afterwards.

1. The four routes, and why route two is usually underrated

There are exactly four things you can do with an on-premise CMMS or EAM, and conflating them is the root of most bad migration decisions. Before comparing vendors, decide which of these you are actually doing.

• Route 1: lift and shift. Take the same product, the same version, the same database and the same customisations, and run them on hosted infrastructure instead of your own server room. Nothing functional changes. You have moved the hosting problem, not solved the software problem.
• Route 2: upgrade to the vendor's cloud edition of the same product. Stay with the product family you already know, move to the current release, and accept the vendor's managed service model. Your data model is broadly familiar, your users recognise the system, and your process documentation survives. Your customisations may not.
• Route 3: replace with a different cloud product. A new platform, a new data model, a new set of interfaces, new training, and a genuine opportunity to change how you work. The highest upside and by a wide margin the highest risk and effort.
• Route 4: stay on-premise, deliberately. Upgrade in place, keep it on your own or a co-located estate, and revisit in a few years. This is a legitimate answer, and treating it as failure is how organisations get talked into migrations they did not need.

The systematic error I see is jumping to route 3 when route 2 would have delivered most of the benefit for a fraction of the disruption. It happens for understandable reasons. The current system is disliked, and people attribute to the product what is actually the result of a poor original implementation, a neglected asset register, and years of local workarounds. Those problems follow you to any new platform. If the dislike is really about data quality and process discipline, changing vendor does not fix it, and you will pay twice: once for the new licence and once for the same unaddressed mess.

The honest test for route 3 is simple. Can you name a capability you genuinely need, that your current product cannot deliver even in its current cloud release, and that materially changes how the maintenance function operates? Mobile that actually works offline, meter driven maintenance, a linear or position based asset model, proper multi entity separation, an API surface you can integrate against. If you can name it, route 3 is defensible. If the answer is "the current system is old and everyone hates it", you have a route 2 problem with a route 3 budget request attached.

2. A route comparison you can take to a steering committee

This is the table I put in front of decision makers early, because it reframes the conversation from product preference to risk and effort. Fill the last column in with your own situation before the meeting.

For the underlying deployment model comparison that sits behind this table, see the cloud based asset management software guide and the cloud versus on-premise CMMS comparison. This article assumes that decision is broadly made and concentrates on the project of getting there.

3. The discovery you must do before you commit to anything

The single highest value phase in a cloud migration is the one that produces no visible progress: finding out what you actually have. Most organisations believe they know their own system and are wrong in specific, expensive ways. The discovery I would insist on before signing anything covers six areas.

• Current version and support status. Exact release and patch level, whether it is still under vendor support, and whether the vendor's cloud edition requires an intermediate upgrade first. Version gaps frequently force a two step path, and finding that out after the plan is approved is a bad day.
• Customisations, and crucially who wrote them. Every screen change, trigger, stored procedure, scheduled job and bolt-on module. For each one: what business need it serves, whether anyone still relies on it, and whether the person or partner who built it is reachable. Undocumented work by someone who left five years ago is the most common single source of schedule slip.
• Interfaces, and what consumes them. Not just the interfaces IT knows about. Trace the outbound files as well as the API calls, and find out who is downstream of each one. Finance, HR, procurement, the BMS, the SCADA historian, a contractor portal, a reporting warehouse, a mobile app.
• Reports, and who depends on them. List them, then check usage rather than asking. A surprising share of the report catalogue has not been run in a year, and two or three unglamorous reports turn out to be the backbone of a monthly contractual or regulatory submission.
• Actual data volume and quality. Row counts per core table, attachment volume and total size, and a real quality assessment of the asset register: duplicates, orphans, blank criticality, locations that do not exist, assets that were decommissioned years ago and never closed.
• The shadow spreadsheets. Every operation runs part of its maintenance in Excel and Access, because the system could not do something and someone worked around it. These do not appear in any inventory. They surface at go-live, when a planner says the new system cannot do the thing they have been doing for six years outside the old one.

The way to find the shadow systems is to ask technicians and planners what they do at the end of each month, not to ask IT what systems exist. The question that works is: "what do you keep outside the system, and why?" People answer it honestly if it is clearly not an audit.

4. Customisations: the dominant cost and the honest reckoning

If one factor decides whether a cloud migration is smooth or painful, it is customisation. On-premise systems accumulate it because they can: you own the database, so someone writes a trigger; you own the application server, so someone adds a scheduled script; a consultant modifies a core screen because it was quicker than changing the process. Cloud editions, whether the same vendor's or a different one's, restrict this deliberately. Multi tenant platforms cannot allow arbitrary code against a shared schema, and even single tenant cloud offerings limit what you may change so they can keep upgrading you.

That means every customisation needs a decision, and the decisions are not comfortable. In practice each one lands in one of four buckets.

• Drop it. Nobody uses it, the requirement has gone, or it was a workaround for a limitation the new release no longer has. The proportion here is always larger than the business initially claims, which is why usage evidence matters more than opinion.
• Reconfigure it. The need is real and the target platform supports it natively as configuration: a field, a status flow, a validation rule, an approval hierarchy. This is the best outcome, because it converts a maintenance liability into supported functionality.
• Rebuild it as an integration or extension. The logic is genuinely yours and the platform cannot express it. It moves outside as an extension using the supported mechanism, or as a small integration service that reads and writes through the API. More work upfront, far more sustainable, and it survives platform upgrades.
• Change the process instead. The uncomfortable one. Sometimes a customisation encodes a local practice that was never a good idea, and the right answer is to adopt the platform's standard way of working. This is a business conversation, not a technical one, and it needs sponsorship because someone will lose an argument.

The pattern I would recommend is to produce a customisation register early, with an owner named against each item, and force a decision on each before the build phase starts. Customisations decided during build become change requests, and change requests become the reason the date moves. This is also the moment to look hard at anything that maintains your own extension code against a cloud platform: the guidance in the configuration versus customisation piece applies to any asset platform, not only Maximo.

5. Interfaces: the hardest technical work, because the other systems stay put

Here is the structural problem with moving a maintenance system to the cloud. The maintenance system leaves the network. Many of the things it talks to do not. Your finance or ERP system may still be on-premise. Your building management system, your SCADA, your historian and your metering are certainly inside the operational network and, if the engineering is sound, deliberately isolated from the internet. The interface that was a database link or a file drop on the same LAN is now a conversation across a boundary that exists for good reasons.

Two interface families dominate the effort:

The ERP interface. Work order costs, purchase requisitions, purchase orders, goods receipt, invoices, cost centres, the vendor master and often the asset financial register. This is the interface with accounting consequences, which means it needs reconciliation controls rather than best effort delivery: an idempotent design so a retry does not double post, a reject queue someone actually monitors, and a period end reconciliation that proves both sides agree. The general patterns are covered in the CMMS to ERP integration guide, and the control that saves you at period end is set out in the three way matching piece.

The BMS and SCADA interfaces. Alarms creating work orders, runtime meters driving usage based maintenance, condition readings against assets. These sources speak protocols that were never designed to cross a public network, and the correct answer is almost never to expose them directly. The pattern that works is a component inside the operational network that collects, normalises and pushes outbound to the cloud platform, so the boundary is only ever crossed in one direction by something you control. The BMS to CAFM reference architecture sets out that shape in detail.

Three practical points that consistently get missed. First, latency and batch windows change: an integration that ran every five minutes over a LAN may need rethinking as a queued, retrying design over the internet. Second, identity changes: interfaces that relied on a service account inside the domain now need token based authentication, credential rotation, and somewhere safe to keep secrets. Third, every interface needs an owner on both sides for the cutover weekend, and in my experience the interface nobody claimed is the one that fails first.

6. Data migration: what to bring, and what to leave behind on purpose

The general method for a maintenance data migration, the extract, transform, validate and load cycle, the mapping workbook, the iteration discipline, is covered properly in the CAFM and CMMS data migration strategy guide, and I will not restate it. What is specific to a cloud target is what you are allowed to bring, how you get it there, and the temptation to bring everything because storage feels free.

The scope decision I would advise, and defend:

• Bring the master data, cleaned. Asset register, locations and hierarchy, equipment specifications, the parts catalogue, suppliers, crews, failure code structures. This is the foundation and it has to be right, because everything else refers to it.
• Bring the live operational state. Open work orders, open requisitions and purchase orders, current PM schedules with their last completion dates and meter readings, current stock balances, open permits, active contracts and warranties. Anything the operation needs on Monday morning.
• Bring recent closed history, selectively. A reasonable window of closed work orders, typically the last one to three years, because planners refer to recent history constantly and reliability analysis needs a running baseline.
• Do not load a decade of closed history as live records. This is the recommendation that meets the most resistance and is almost always right. Ten years of closed work orders, their task lines, labour, parts and comments, inflate the migration effort, slow every validation cycle, and add risk for data that will be read a handful of times a year.

Attachments deserve their own line. Photographs, manuals, scanned permits and signed job cards are usually the largest volume by size and the most awkward to move, because they live on a file share with paths recorded in the database. Count them and total their size during discovery, test the transfer rate early, and decide explicitly whether older attachments go to an archive rather than into the new platform's document store.

Then the unglamorous technical detail that causes go-live incidents: units of measure that differ between systems, currencies and exchange rate handling on historical cost, date and time zone semantics when the platform is hosted in a different region than the operation, and character encoding on any field that ever held a non standard character. Each of these is easy to fix during mapping and genuinely difficult to fix after load.

7. Cleaning the asset register, before the migration and not after

This is the section I would keep if I had to cut the rest. A migration is the only realistic opportunity you will get to fix the asset register, because it is the only time the whole organisation accepts that data has to be reviewed. Once the new platform is live, appetite evaporates, and whatever you loaded becomes the permanent truth.

The cleanup that actually matters:

• Duplicates. The same physical asset recorded two or three times because it was created by different teams, or re-created after a rename. Duplicates fragment history and quietly ruin every reliability metric you will later try to calculate.
• Orphans. Assets with no valid location, no parent, or a parent that no longer exists. These vanish from hierarchy driven reports and only surface when somebody notices a total does not add up.
• Ghosts. Assets disposed of or replaced years ago that were never retired, still carrying live PM schedules. Every one of them generates work that gets cancelled, which corrupts schedule compliance.
• Missing classification. Blank or inconsistent asset class, criticality and cost centre. Without these the new platform cannot prioritise, group or report, no matter how good it is.
• Hierarchy that does not reflect reality. A structure built for the original implementation and never revisited as sites, systems and ownership changed.

Do this work against the extract, in a workbook or a staging database, with maintenance supervisors validating their own areas. Two things make it succeed: assign areas to named people rather than to a committee, and give them a short, hard deadline, because data cleansing expands to fill whatever time it is given. The structural guidance for what "good" looks like is in the asset hierarchy design guide and the asset master data management piece.

8. History retention and the read-only archive pattern

If you are not loading a decade of closed history, you need a defensible answer to "where did it go", because someone will ask, and in regulated or contractual environments they are entitled to. The pattern that works is a read-only archive.

Keep a full copy of the legacy database, restored and running, with read access for a named group and a documented retention period. Alternatively, extract the history to a structured store, a reporting database or a set of files in a recognised format, with a simple query or report layer over it. Either way, three things make it genuinely usable rather than a box tick: it must be searchable by asset and by date, someone must own it, and the route to it must be written into the support documentation so a planner in two years knows how to ask.

The important caveat: an archive is only a valid answer if the retention obligation is satisfied and someone has checked. Warranty claims, statutory inspection records, safety related maintenance evidence and contractual performance history may all have defined retention requirements, and an archive nobody can query does not meet them. Confirm the obligation with whoever owns compliance before you decide the cut-off, not afterwards. The warranty management guide covers the claim evidence side of this.

One more option worth considering: load a summarised history rather than the full detail. Work order header, asset, dates, failure code and total cost, without the task lines and transaction detail. It preserves the reliability analysis and the trend view at a small fraction of the volume, and it satisfies most of what planners actually reach for.

9. Cutover: big bang, phased by site, or parallel running

Three cutover approaches exist, and the choice depends on interface complexity, the number of sites and how much operational risk the business can absorb over a weekend.

For a single site with a small number of interfaces, big bang is usually right and a phased approach just adds cost. For a multi site estate, phased by site is the pattern I would default to, with the pilot chosen for a manageable size and a cooperative team rather than for being the most important site. On which, the split estate problem is real: for the period between waves you need a defensible answer for group level reporting, and the honest answer is often "consolidated reporting resumes when the last site lands", which is easier to accept if you say it in advance.

10. Testing, UAT with real technicians, and reconciliation

Testing a migration has two halves that get confused: does the software work, and did the data arrive intact. Both need to be planned and neither substitutes for the other.

On the software side, the sequence that works is unit and configuration testing by the build team, then end to end process testing across integrated systems, then user acceptance testing, then a performance check at realistic data volume. Performance deserves a specific mention on a cloud target: a screen that felt instant over a LAN behaves differently over the internet from a site with constrained bandwidth, and a mobile app in a plant room with poor coverage is a different test again. Test from the worst location you actually operate in, not from the office next to the project room.

On UAT, the rule I would not bend: real technicians and real planners, doing their own work on their own assets, not a business analyst following a script. Scripted UAT passes and then go-live reveals that nobody can find the assets they work on, because the hierarchy was reorganised without their input. Technician UAT is also the cheapest possible place to discover a shadow spreadsheet, and it reliably finds two or three.

Reconciliation after each migration run is a formal, signed activity, not a spot check. The minimum set:

• Record counts per object, source against target, with every difference explained and accepted rather than noted.
• Financial and quantity totals reconciled: stock value and quantity by store, open purchase order commitment, open work order cost to date.
• Hierarchy integrity checks: no orphans, no cycles, every asset in a valid location, parent counts matching.
• PM schedule verification: next due dates recalculated in the new system against expected dates from the legacy last completion. This is the check most often skipped and it decides whether the first month generates the right work or a flood of the wrong work.
• Attachment spot checks across a sample of assets, confirming the document opens and is the right document.

For the reporting side, remember that reports built on a new data model need their own acceptance, not an assumption. The approach in the BI report testing and UAT piece transfers directly: reconcile each critical report against a known period in the legacy system before anyone relies on it.

11. Training and adoption, which is where the value is won or lost

A technically perfect migration with poor adoption is a failed migration. The system is judged in the first fortnight by the people who use it most, and if they cannot complete a work order without asking someone, that verdict sticks for a long time.

What I would recommend:

• Train by role and by task, not by module. A technician needs to receive, execute, record and close, on the device they carry. That is the training. They do not need a tour of the configuration screens.
• Train late, close to go-live. Training delivered two months early is forgotten. Two weeks is about right, with refresher access to a practice environment.
• Use migrated data in training. People learn on their own assets and their own locations far faster than on demonstration data, and it doubles as a data quality review.
• Name super users per site. A visible, trained, respected first line who answer the small questions locally. This does more for adoption than any amount of documentation.
• Over resource the first two weeks. Floor walking support in the plant and at the desk, a single obvious route to raise a problem, and visible fast resolution of the small irritations.

And be honest with the sponsor: productivity dips after go-live, for a few weeks, always. Planning for that dip with extra support and a reduced discretionary workload is professional. Pretending it will not happen means the dip gets interpreted as the project having failed.

12. The rollback plan and the point of no return

Every cutover plan needs a rollback plan that has been written down, rehearsed, and given a decision deadline. Not a paragraph saying "revert if required", but a sequence: who decides, by what time, against what criteria, what gets reversed, and how the legacy system is brought back into service with any transactions entered since the freeze.

Two points that matter more than the document itself. First, the go or no-go decision belongs at a stated time with stated criteria agreed in advance, because at two in the morning with the team exhausted, nobody makes a good judgement call from first principles. Second, there is a genuine point of no return, and you should know exactly where it is. Once the ERP interface has posted a period's transactions from the new system, or once technicians have been closing work in it for several days, rolling back means losing real operational and financial data. After that point the only route is forward with fixes, so the plan should switch explicitly from rollback to remediation, and everyone should know the moment that switch happens.

Related, and frequently forgotten: decide in advance how long the legacy system stays available read-only after cutover, who may access it, and when it is finally decommissioned. Leaving it fully live and writable is an invitation for someone to keep using it, which quietly splits your system of record in two.

13. A realistic phase plan with gates

Durations depend on the route, the number of sites, the number of interfaces, how much customisation exists and how bad the data is, so I will not give you a number of weeks and pretend it is transferable. What is transferable is the sequence and the gate at the end of each phase. A phase that has not met its gate should not hand over, and the most common cause of a failed go-live is a gate waved through under schedule pressure.

Note that data cleansing runs alongside build rather than after it. Sequencing it as a post-build task is the single most reliable way to miss the date, because cleansing depends on people who have day jobs and cannot be compressed by adding project staff.

On the point of go-live itself: it does not mean finished. It means the system is in use and the remaining work has changed character. PM generation needs watching over the first few cycles. The first period end with finance is a real test that has not happened yet. Reports get rebuilt as people discover what they actually need. Adoption habits form over a quarter, not a weekend. Treating go-live as the end, and releasing the team the following week, is how organisations end up with a modern platform being used like the old one. For the wider programme framing beyond the migration itself, the CMMS implementation plan and the operational view of cloud facilities and maintenance management are the natural next reads.

The idea to walk away with

A cloud migration is not a technology exercise with a data task attached. It is a data exercise with a technology change attached, and the organisations that understand that finish on time. Choose the route on evidence rather than frustration, and check route 2 properly before you commit to route 3. Do the discovery before you sign, because the customisations and interfaces you have not found yet are the ones that will set your timeline. Treat the customisation register as a set of decisions to be forced early, not a backlog to be discovered during build. And take the chance the migration gives you to fix the asset register, because you will not get another one for years, and everything you defer becomes permanent the day you go live.

The cutover itself is the part everyone worries about and, with rehearsed loads, a signed reconciliation and a real rollback deadline, it is the most controllable part of the whole programme. What is genuinely hard is the cleanup, the interfaces across the network boundary, and the adoption. Put your senior attention there.

Final thoughts

If I had to reduce this to one piece of advice, it would be to separate the three things that get bundled together in the phrase "we are moving to the cloud": changing where the software runs, changing which software you run, and fixing the data and processes underneath. They are independent decisions with different costs, and bundling them is why migrations become programmes and programmes become overruns. You can move hosting without changing product. You can fix data without changing either. Knowing which of the three you actually need is most of the value an advisor adds.

And be realistic about what cloud does and does not deliver. It removes infrastructure work, keeps you on a current release, and makes integration and mobile access easier. It does not clean your asset register, will not resolve a process disagreement between maintenance and finance, and will not make a system credible to technicians who could not find their own equipment in it. Those remain your work, and they are the work that decides whether the migration was worth doing.

Related reading: Cloud based asset management software, Cloud CMMS versus on-premise, CAFM and CMMS data migration strategy, Asset hierarchy design, CMMS to ERP integration, BMS to CAFM reference architecture, Cloud facilities and maintenance management.

External references: ISO for the asset management and information security standards referenced in most migration governance, and NIST for cloud and operational technology security guidance worth reading before you expose any plant network interface.