Why Elevator Software Implementations Fail in Month Four
By Mr. Sumeet Katariya, Founder & CEO, ElevatorPlus · Published 20 August 2026 · Last updated 20 August 2026 · ~6 min read
In short: Almost every elevator company that has abandoned a software platform describes it afterwards as bad software. Usually it wasn't. Across the implementations we see, five failure patterns account for most abandonments, all of them visible by month four, and all of them decided long before the platform was chosen. Here they are, and here is how to see them coming.
Key takeaways
- In the implementations we watch, month four is when abandonment becomes visible, but the cause is almost always set in weeks one to three.
- The most common single cause is incomplete data migration. A system that holds 70% of your portfolio is not a system, it is a second place to look.
- Implementations fail on ownership more than on features. If nobody's actual job depends on the rollout working, it will not.
- Parallel running with the old method is the most requested and most destructive transition plan.
- The honest self-assessment: if your business has abandoned software before, the next platform is unlikely to fix that on its own. Look at the pattern, not the product.
What this guide covers: the five failure patterns · why month four · what a survivable rollout looks like · the questions to ask yourself before buying · FAQs.
Why month four specifically?
Because of how enthusiasm decays, and we watch the same curve run through implementation after implementation.
Month one is momentum. The decision is fresh, the vendor is attentive, everyone is being reasonable about teething problems.
Month two is configuration. Real edge cases surface: the contract that bills differently, the customer with eleven buildings, the technician who covers two territories. Workarounds get invented.
Month three is quiet. Vendor onboarding calls taper off. The internal champion returns to their day job. Nobody is watching whether usage is holding.
Month four is when someone in a management meeting asks why the reports still don't match reality, and the answer is that half the team stopped entering data six weeks ago.
Nothing dramatic happens in month four. It is simply when the gap between what was bought and what is being used becomes impossible to ignore.
Nobody abandons software in a meeting. It goes one Tuesday, when a technician cannot find something, uses WhatsApp instead, and nobody corrects it.
Failure one: the data never fully arrived
This is the biggest, and it is almost always underestimated at the point of purchase.
Migration gets scoped as a task. In reality, an elevator company's data lives in four places at once: a spreadsheet, an accounting system, a filing cabinet, and the owner's head. The first two can be exported. The third takes weeks. The fourth requires sitting with someone and asking questions.
When migration is partial, the effect is corrosive rather than dramatic. Staff learn that the system is unreliable. Not wrong, just incomplete. So they check it and the old place. Once people are checking two sources, the old source wins, because it is the one that has never let them down.
The tell: anyone in the business saying "it's mostly in there." Mostly is the failure state.
Failure two: nobody actually owned it
Every failed implementation had a project owner on paper. Very few had one whose job depended on it.
The pattern is familiar. The owner sponsors the purchase but delegates the rollout. The operations manager is nominated but has a full-time role already. The vendor provides onboarding, which is support, not ownership.
So when a decision is needed, such as whether to change how contract types are coded, or whether to insist technicians close jobs on site, nobody has both the authority and the incentive to make it. The decision defaults to "leave it as it is," which means the old way.
What works: one named person, explicit authority to change process, and a specific outcome they are accountable for at 90 days. Not "implement the software." Something measurable: every unit in the system, every renewal date tracked, technicians closing 90% of jobs on site.
Failure three: parallel running
Covered at length in our piece on what technicians will actually refuse to use, because it is where the damage lands hardest.
The short version: keeping the old method alive "until we trust the system" doubles the work for the people doing the entering and guarantees that one of the two channels gets done badly. It will be the new one, because the old one is what the supervisor still checks.
Clean cutover on a small scope beats hedged cutover on a large one. Every time.
Failure four: it was bought to solve a problem nobody had agreed on
Ask three people in an elevator company why they are buying software and you can easily get three answers: the owner wants visibility on margin, the operations manager wants dispatch to stop being chaotic, the accountant wants invoicing to speed up.
All three are reasonable. They imply different configurations, different rollout priorities and different definitions of success.
When the goal is unstated, month four arrives with the system partially serving all three purposes and fully serving none, and each of the three concludes independently that it didn't work.
The fix costs nothing: before you buy, write one sentence describing what must be true in 90 days. Get the three people to agree on it. If they can't agree on the sentence, the software was never the problem.
Failure five: the process problem was never a software problem
The uncomfortable one.
If renewals are missed because nobody has been made responsible for them, a system that tracks renewal dates will surface the problem more clearly and change nothing. If technicians don't close jobs because there has never been a consequence for not closing jobs, an app will not create one.
Software makes a good process faster and a broken process visible. It does not repair the process. Implementations that assumed otherwise tend to be the ones described afterwards as "the software didn't do what we needed."
| Failure | Visible symptom by month 4 | Actually decided in |
|---|---|---|
| Partial data migration | Staff check two places | Week 1–3 |
| No real ownership | Decisions default to the old way | Before purchase |
| Parallel running | New system half-populated | The rollout plan |
| Unagreed objective | Three people, three verdicts | Before purchase |
| Process problem, not software problem | Same failures, now visible | Long before purchase |
👉 See what a 90-day rollout with a named outcome looks like. Book an ElevatorPlus demo →
What a survivable rollout looks like ?
Four things, none of them about the software.
Complete the data before going live on anything. Every unit and every contract, with the renewal dates attached. Partial is worse than late.
Name one owner with authority and a measurable 90-day outcome. Their performance review should mention it.
Cut over one scope cleanly rather than everything partially. One crew, one route, one contract type. No parallel paper.
Agree the single sentence before you sign. What must be true in 90 days, agreed by everyone who will judge the result.
Do those four and platform choice matters far less than anyone expects. Skip them and platform choice matters not at all.
Frequently asked questions
Why do elevator software implementations fail?
Most commonly: incomplete data migration, no genuine internal ownership, running in parallel with the old method, disagreement about what the software was for, and trying to fix a process problem with a tool.
How long does it take to know if an implementation is working?
In what we see it shows at about four months, though the cause is set in the first three weeks. Falling usage in weeks three to six is the earliest warning sign we have found.
Should we migrate all our data before going live?
Yes. A system holding most of your portfolio teaches staff to check two places, and the old place always wins that contest.
Who should own a software rollout in an elevator company?
One named person with explicit authority to change process and a specific, measurable outcome they are accountable for at 90 days. Vendor onboarding is support, not ownership.
We've abandoned software before. Will a different platform work?
Possibly, but look at the pattern first. If the previous failure was migration, ownership or process rather than features, a new platform on the same approach will produce the same result.
Is it better to roll out gradually or all at once?
Neither extreme. Cut over a small scope completely rather than a large scope partially. Full commitment on one crew or route beats half commitment across the business.
Month four is not when software fails. It is when the failure becomes visible.
The decisions that determine the outcome are all made before or immediately after purchase: whether the data is complete, whether anyone truly owns it, whether you cut over or hedge, whether everyone agrees what success means. Get those right and most platforms will work. Get them wrong and none will.
👉 Talk through the rollout, not just the product. Book a demo →
Related reading
- What Your Technicians Will Actually Refuse to Use
- Build vs Buy: Should an Elevator Company Build Its Own Software?
- Elevator Software Buyer's Guide: 12 Questions to Ask Before You Choose
- The Second-Generation Question: When the Son Wants Systems
About the author: Mr. Sumeet Katariya is Founder & CEO of ElevatorPlus, the Elevator Business Operating System used by 200+ elevator companies across 20+ countries, and author of "ElevatorPlus — How to run your operation stress-free and 3x your business".
Sources: ElevatorPlus implementation and onboarding observations across our own customer base of 200+ elevator companies in 20+ countries, 2026. The month-four timing, the weeks one to three cause window, the weeks three to six warning sign and the five failure patterns are what we observe in our own implementations, not findings from published enterprise software adoption research.
👉 Follow ElevatorPlus on,
Instagram LinkedIn Facebook YouTube Qoura Substack Twitter
