There are few projects in facility management that are as reliably romanticized as the Replacement of a CAFM system. On paper, it always sounds wonderfully simple: old system out, new system in, data migrated, processes modernized, everyone happy, operations more efficient, reporting cleaner, users enthusiastic, management impressed.
In practice, this is about as realistic as the idea that you can clear out a cluttered basement by simply sticking a label on the door and then ordering a new shelf. The CAFM implementation guideline describes decommissioning as its own phase, but at the same time makes it clear that this is precisely where the project receives its last major test: data, processes, operation, migration, expectations, and organization must align.
The Actual Mission
The official narrative for replacement sounds something like this: We'll take over everything relevant, we'll clean up the old, we'll introduce the new in a structured way, and afterwards, everyone will work more efficiently than ever before. The real narrative is more like: We need to find out, which data is still correct at all, who maintains them, why they exist, why they are listed 5 times in 3 different fields, and why no one knows anymore whether the room ID, the asset ID, and the Excel column "Object old final really final (b)" really mean the same thing. My colleagues in consulting also emphasize repeatedly that a CAFM implementation does not begin with purchasing software, but with analysis, goal definition, data evaluation, and migration strategy — and that a clean migration strategy is particularly crucial for replacements.
Therefore, replacement is not an IT swap, but a mix of organizational appendectomy and roof renovation: you remove something old that is annoying but somehow still keeps things going, and hope that half the building doesn't collapse underneath. The most common misconception is that a new system automatically generates better data. This works about as reliably as a new kitchen automatically producing better food.
The Holy Data Migration Fairy Tale
The first myth is: "We'll just take over all the data." That sounds reasonable, but in practice, it's an invitation to disaster with a start date. Because "all data" doesn't mean "all useful data," but usually a mix of master data, legacy issues, duplicates, remnants of history, half-maintained workflows, unclear status fields, orphaned objects, and lovingly maintained Excel graveyards. Precisely for this reason, it is explicitly pointed out in practice that only cleaned, consistent old data should be transferred during migration and that data cleaning is mandatory before dumping it into the new system.
Especially when transferring data graveyards , the true art becomes visible: The problem is not the migration, but the decision what is still a data record at all and what is already historical sediment. In many inventories, there is data that is formally present but functionally dead. An asset exists in the list but no longer in the building. A room is still set up, even though it has been a copier area, then a meeting room, and now a storage room for three renovations. A contract is still active, even though the service provider has long since changed. And somewhere it still says: "Data inventory OK." Yes, as complete as a ruin can be.
Costs: The Real Language of the Project
When costs are discussed in CAFM projects, it rarely means just the software license. Honestly, we would have to look at license costs, implementation, training, data migration, interfaces, hosting, ongoing operation, and support as relevant cost blocks. It is particularly interesting that the published orders of magnitude per workstation can vary widely, and training and onboarding form significant cost blocks of their own.
This is also logical: Replacing CAFM software is not an isolated software implementation, but a restructuring of data, processes, and responsibilities. Anyone who believes the project ends with ordering the license has not accounted for the species that appear at some point in every CAFM project: the data cleaner, the interface architect, the process rescuer, the Key users with burnout warning signs and the decision-maker who asks why all of this wasn't productive yesterday (you know them too, don't you?). The cost of a CAFM change therefore consists not only of money, but also of time, patience, attention, and political wear and tear.
It gets even worse when the expectation is that the replacement can be done 'on the side'.
This is roughly like replacing a main distribution board while operations continue, and then being surprised to find that circuits and corporate reality do not always share the same sense of humor. In practice, the cost framework shifts almost always, because unclear old processes, missing data quality, and additional interfaces only become visible during the project. What initially looks like an orderly system often turns out to be archived improvisation with usage rights.
The Process You Inherit
Perhaps the most uninspiring truth about a CAFM replacement is: you don't just replace software, you inherit processesAnd inherited processes are like antique furniture from an IKEA-influenced family apartment — they have history, but nobody knows why they're still around. Everyone should (!) realize that the current state analysis is precisely why it's so important: weaknesses, media breaks, duplicate entries, and unclear responsibilities must become visible before the replacement.
In reality, however, something else often happens. You take the old process, put it into a new interface, and call it transformation (or "CAFM 4.0"). Then a workflow that was already nonsensical in the old system is reproduced in the new system with more modern buttons, prettier colors, and perhaps even an app. The result is not digitalization, but industrial refinement of nonsense. The new process is faster, prettier, and unfortunately still wrong. One could almost applaud if it weren't so expensive.
Therefore, in a replacement, the most dangerous statement is not "The old system is bad," but "We want to adopt the existing process." This is convenient because it avoids conflict. However, it is usually precisely the decision with which you pay for a new system to now execute the old deficiency in high gloss.
Expectations from a Parallel Universe
A central problem is misguided expectations regarding feasibility, price, and time horizon. The 'official' project logic in GEFMA-related descriptions includes phases from analysis, requirements catalog, and implementation to replacement; thus, this replacement is not the end of the project, but an independent step that must be carefully planned. Nevertheless, in many organizations, people act as if the change is a procurement act followed by a miracle cure.
The wish list then reads something like this: please provide all data completely, please standardize all processes, please no restrictions, please be individually tailored enough for our specific needs, please integrate cleanly into ERP, DMS, GIS, and building automation, , please inexpensive, please fastwith no training effort, please with high user acceptance starting next quarter. So, one wants the Ferrari price, the bicycle feeling, and the reliability of a scheduled bus on a holiday, all at the same time. Technically, this is about as sound as the idea of remediating a water damage project with a single moisture meter and a PowerPoint slide.
In reality, CAFM systems often have to be connected to ERP, DMS, GIS, BIM, and technical systems via interfaces, and data migration, training, and operation are an integral part of the service package. This directly leads to: those who underestimate the replacement effort have usually not miscalculated, but thought incorrectly.
The project is rarely too expensive because CAFM providers and consultants are too greedy; it is expensive because organizations only discover their own complexity when someone writes a schedule for it.
Data Graveyard with a Login
The data graveyard is the actual main actor in every CAFM replacement. It has many tombstones, but no flowers.
It consists of data that was once important, then half-heartedly maintained, finally existed only out of habit, and is now given the honorary titles of "old stock" or "historical data." The problem isn't that this data exists. The problem is that nobody wants to let go of it as long as it's not clear whether it might, might, might still be needed s-o-m-e-w-h-e-r-e.
And of course they are needed — usually by the one department that reports in five minutes before go-live and says that the last eight years should please also be migrated because they want to access it "for audits." "We need this for audits" is the magic phrase in the CAFM context that gives every data corpse renewed social relevance. Then tidying up suddenly becomes archiving, archiving becomes a migration package, and a migration package becomes an additional budget.
The technical answer to this is actually clear: Not everything old belongs in the new. For future use, only cleaned and consistent data should be transferred, while the rest is archived or otherwise secured. The organizational answer is significantly more complicated: "We'll do that later."
However, later in CAFM is the place where good intentions die and project budgets are stretched to the limit.
The Bad Old in New Clothes
A CAFM replacement fails not only due to data but also due to the longing to uncritically perpetuate the old. Many organizations want a new system but not a new working style. You want modern transparency, but the old freedom of Excel. They want clean data, but please without cleaning. They want compliance, but without documentation-intensive maintenance. They want standards, but of course specifically for their special cases (and believe me, I've heard exactly that what feels like 1000 times...).
GEFMA emphasizes (and not just them...) that an implementation always involves Requirements analysis, process mapping, data concept, and project organization and that the replacement must be a conscious renewal phase This is important because otherwise, in the end, you only renew the surface. The system looks new, but under the hood, the same habits continue to live like cockroaches after renovation. This is not progress, but merely better-lit dysfunction.
It becomes particularly painful when old processes are not just bad, but political entrenched. Then the question is no longer how a process should function technically, but who pressed which button in the old system and why no one wants to remember it anymore. A replacement therefore not only forces organizations to migrate technically but also to self-critique. And that's precisely the moment when the project team, with a serious look, says 'Change Management,' while in the background, five people are already backing up their Excel favorites ;-)
Practice of Reality
Practical examples from current CAFM projects show how broad the requirements for systems and migration actually are. Manufacturers describe typical integrations with SAP, DMS, GIS, BIM, IoT, ticketing, and mobile solutions; at the same time, data migration, data acquisition, training, and support are listed as part of the overall package. This clearly shows that a replacement is not purely a software decision but an ecosystem change.
A practical case is the replacement of a system in which areas, assets, tickets, and contracts have grown historically but were never truly harmonized. Then, before migration, it must first be clarified which data model will apply in the future, which fields are technically binding and which information only has a place in the archive. This is precisely why project methodology demands an early analysis of data quality and target structure.
Anyone who skips this step does not migrate knowledge, but solidifies confusion.
Another type is the replacement of a system that was originally intended for a very small application case and later mutated into a universal system. Into a beast. Then everyone somehow worked with it, but nobody adhered to a common data standard. The new solution is then suddenly supposed to deliver reports, mobile processing, workflows, compliance, and management decisions. This is the point where the project slides start to become insulting.
Why Budgets Fail
Many budgets fail not because of their amount, but because of their incompleteness. Cost overviews often mention software, maintenance, hosting, and training, but the real explosive potential often lies in data cleansing, migration effort, interfaces, clarifying roles, test runs, and rework. Therefore, technical guidelines emphasize that solid budgeting should always include buffers and risk assessment. But no one wants to hear that.
The punchline: The worse the starting situation, the more urgent the replacement seems — and the more unwilling one is to acknowledge the realistic costs. One prefers to invest in hope rather than in preparation. This is about as sensible from a business perspective as buying a fire extinguisher on the grounds that one hopes not to need it. If the existing inventory is chaotic, time and costs inevitably increase. This is not malice on the part of the consultants, but the stark logic of data and organization.
The assumption that one can minimize the migration effort through a “clever” tender is particularly popular. This usually only leads to the project starting cheaply and ending expensively. A clear scope of services is more pleasant than a beautiful illusion.
Practice shows quite clearly that the data and migration concept must be centrally considered as early as the preparation phase.
Timeline based on wishful thinking
There is also often a poetic vagueness regarding the schedule. People then say things like: “We want to introduce this during the year” or “this should be productive by the end of Q3.” This sounds serious, but is often about as precise as “we’ll just renovate it properly.” Technically, the duration of a CAFM implementation is strongly influenced by data quality, training, complexity, and scope; we often describe a multi-phase approach with analysis, tendering, implementation, use, and later replacement. In practical descriptions, different implementation durations and training efforts are mentioned depending on the scope. But who does this consistently?
The problem is: The timeline, in wishful thinking, usually only considers the software configuration. In reality, however, the Preliminary work often take longer than implementing the system. Data must be identified, cleaned, mapped, tested, and professionally approved. Processes must be defined, discussed, adapted, and sometimes politically enforced politically enforced. Anyone who plans too tightly for this not only creates stress but also quality losses. And quality losses in CAFM later manifest in reports, tickets, maintenance, and ancillary cost statements — precisely where they are least needed.
What Works Well
Despite all this, replacing CAFM software is, of course, sensible if it is set up correctly. Current CAFM solutions typically offer significantly better integration options today. Or mobile usage, user-defined reporting, and customizable process support.
However, the best chance of success never lies in hoping for the perfect tool, but in an honest assessment of the current situation. Those who ask early on which data is really needed, which processes are really sensible, and which old burdens they really want to carry into the future will ultimately save money and nerves. And those who accept that a replacement is an organizational project, not just a software project, are already further ahead than many others. The replacement will still be strenuous, but at least no longer naive.
The real joke about CAFM replacements is that they almost always fail precisely where everyone was most confident: with the data, with the processes, and with the expectations. Not with the button design. Not with the logo. Not with the question of whether the dashboard is green or blue. But with the question, whether one has understood one's own inventory at all.
Data completeness, data quality, migration strategy, stakeholder involvement, prioritization, and realistic project management are the actual success factors.
And perhaps that is precisely the point for my somewhat malicious blog post about replacing CAFM systems: you don't just replace an old system with a new one.
One decides whether to continue managing one's own organizational reality or finally start to organize it. This is less glamorous, costs more, takes longer, and rarely ends with confetti. But that's precisely why it sometimes even works.
