The Handover: Twenty Years of Paper Into a System
By Mr. Sumeet Katariya, Founder & CEO, ElevatorPlus · Published 29 August 2026 · Last updated 29 August 2026 · ~7 min read
In short: Moving twenty years of lift records into a system is not a typing job. The hard part is deciding what the records mean. Capture the portfolio first, then the exceptions and the reasons behind them, then run both ways of working side by side until the comparison stops producing surprises.
Key takeaways
- The bottleneck is never data entry. It is judgement: which rates are deliberate, which are accidents, and which nobody remembers agreeing to.
- Capture the portfolio first. Every lift, building, contract and renewal date. In most firms this list has never existed anywhere except in one person's head.
- Then capture the exceptions and their reasons. A rate without its reason is a rate the next generation either raises and damages a relationship, or holds forever without knowing why.
- Run both systems in parallel for a period. If the system misses something, fix the configuration. If the old way misses something, that makes its own point.
- Twenty years of paper does not all need keying in. Decide what to leave behind deliberately, not by exhaustion.
What this guide covers: Why data entry is the easy part · Capturing the portfolio · The exceptions and the reasoning · What not to migrate · Running in parallel · Who does the work · The physical paper · FAQs
Why is the hard part not data entry?
Because you can hire data entry. You cannot hire the reasoning.
Names, addresses, unit counts, dates: two decades of files can be typed up in weeks. That is a cost, not a problem.
The problem arrives at the third file. A building on an AMC well below the going rate for that size and age of machine, nothing in the file explaining it. You ask the founder and he answers without hesitating: the secretary's father gave us our first eleven contracts in 1998, and we have never touched his building's rate.
That is not in any file, and it is not a mistake either. It is a commercial decision, made once, honoured for decades, understood by exactly one person. Multiply it by the oddities in any long-running portfolio and you have described the real work of a handover.
What do you capture first?
The portfolio. Nothing else, at the start.
Every lift with its building. Every building with its client. Every contract with its scope and renewal date. That is the spine, and everything else hangs off it.
Two things happen. First, somebody says quietly that this list has never existed before, nowhere except the founder's memory and ledgers organised by year rather than by client.
Second, the count comes out wrong, usually low. Units serviced for years with no active contract. Two entries for one lift under different building names. A building demolished in 2019 still on the books. Treat that as a result, not an embarrassment.
Get the spine right and stop. Do not wander into history on the same pass.
Why are the exceptions the part that matters most?
Because this is the part everybody skips, and the part that costs money later.
Every long-running lift business has arrangements that make no sense on paper: the discounted rate, the quarterly payer in a portfolio of annual ones, the free callouts nobody wrote down, the building where the same technician always goes because the secretary will deal with nobody else.
Record all of it, and record why.
A rate without its reason is a trap for whoever comes next. The successor sees an outlier, does the sensible thing, corrects it to market, and loses a relationship carried deliberately for twenty years. Or he is told not to touch it, given no explanation, and holds it forever, still discounting a building whose original reason died a decade ago.
Both failures come from the same missing sentence.
So the reason goes in the record. "Rate held since 1998, first client, founder's decision, review only if management changes." That sentence is worth more than the rate field beside it, because it survives the founder's retirement.
We have watched second-generation clients including Shree Jee Elevators in Mumbai, Hephzi Elevators in Bengaluru and Global Elevators in Mumbai work through this stage. In each case the useful output was not a cleaner database. It was a set of written reasons that had existed only as one man's judgement.
👉 Twenty years of judgement is worth writing down before it walks out of the office.
Why run both systems in parallel?
Because the comparison settles arguments that would otherwise run for months.
Pick a period, usually a month, and do everything twice. Then read the differences carefully, because they mean two opposite things.
| What the comparison shows | What it actually means | What you do about it |
|---|---|---|
| The system missed a renewal the register caught | The old way was right. The configuration is wrong. | Fix the setup, usually a renewal rule or a contract type nobody mapped. |
| The system billed a client the ledger did not | Either an old unbilled unit or a duplicate record. | Correct the data, then ask why the old way lost it. |
| The old way missed a renewal the system caught | This is the argument you were going to have, answered without anyone arguing. | Nothing. Let it sit there. It makes its own point. |
| Both agree, all month | Parallel running has done its job. | Stop. Do not extend it out of nervousness. |
That third row is why the duplicated effort is worth it. A missed renewal in a real month, with a real client name on it, is not an opinion, so nobody has to win the debate about whether the old way was good enough.
Then stop. A parallel run that outlives its usefulness becomes two permanent systems, which is worse than either alone.
What does not need migrating?
Most of it, honestly.
Twenty years of paper does not all need keying in, and pretending otherwise is how these projects die. Somebody sets out to digitise everything, gets back to 1994, quits in month three, and the effort gets written off as a failure when what failed was the scope.
So decide at the start. Migrate the live portfolio, current contracts and rates, open defects, current certificates with expiry dates, active contacts, and the exceptions with their reasons. Keep but do not migrate settled invoices, superseded contracts, completed jobs beyond your retention requirement, correspondence on closed matters. Migrate selectively unit-level repair history: full history for machines you still service, nothing for units long gone from your portfolio.
Leaving something behind is a real decision. It deserves somebody with authority, a meeting and a reason. What it must not be decided by is exhaustion.
Who should actually do the work?
The founder dictating and somebody else typing.
Not the founder learning the software. Not the son entering what he thinks he knows and asking his father to check it afterwards.
The framing matters more than it sounds. Put a man who built the business in front of a screen he has never used and ask him to enter records, and you have made him a student in his own company. Many will find reasons not to, and those reasons will sound like objections to the software.
Sit him with the files, ask him about each client, and have his son or the office manager type while he talks. Now everything is the right way round. He is the source, and the system is taking dictation from the person who knows. His authority stays intact because the framing is accurate: he does know things nobody else knows, and the exercise proves it rather than testing him.
Pace is twenty to thirty clients a session before attention goes. Two sessions a week.
What happens to the physical paper?
Do not shred it on the day the system goes live.
Keep it, boxed and labelled by client rather than by year, for as long as your obligations require. Retention periods for maintenance records, test certificates and statutory examination reports differ by jurisdiction, and in several countries the lift-specific requirement runs longer than the general commercial one. Check what applies where you operate rather than assuming, and if you work across borders, apply the longest.
Once retention is satisfied and the live data verified, the boxes can go. Most firms never open them again after the fourth month, which is a reason to stop storing them in the office, not a reason to destroy them early.
Frequently asked questions
How long does a handover like this take?
For a few hundred lifts, weeks rather than days for the portfolio and longer for the exceptions, which depend on one person's availability.
Should we digitise all twenty years of records?
No. Migrate the live portfolio, current contracts, open defects, current certificates and unit history for machines you still service. The rest is storage, not data.
Why not get the office to enter everything and check it later?
Because data without reasons looks complete and is not. An exception typed as a plain number loses the sentence that made it make sense.
What if the founder resists the whole idea?
Usually he is not resisting the system, he is resisting being made a beginner. Change the shape of the exercise so he is the source and somebody else works the keyboard.
What if the system and the old register disagree?
Investigate every difference. Configuration errors and genuine gaps in the old way look the same at first glance and require opposite responses.
Who should own the project day to day?
Somebody with authority to make scope decisions, usually the second generation rather than an administrator. Otherwise every judgement call gets escalated and the work stalls.
What is the first sign it is working?
Somebody answers a client's question about their lift without ringing the founder.
A handover is not a data migration with a family attached. It is the transfer of judgement from a person into a record, and the typing is the least interesting part of it.
Get the portfolio down. Get the exceptions down, with reasons. Run both ways side by side until the differences stop being interesting. Decide out loud what you will not carry forward.
Then the business stops depending on one man's memory. That is the only version of a handover that works.
👉 Ready to get twenty years of records into one place?
Related reading
- The Second-Generation Question: When the Son Wants Systems and the Father Built the Business Without Them
- Independence From Spreadsheets: What Running 20+ Countries on One System Looks Like
- Seven Lift AMC Contract Clauses That Decide Whether You Make Money
- The Complete Lift Maintenance Checklist for 2026
About the author · Mr. Sumeet Katariya is Founder and 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 client onboarding observations, 2026. Shree Jee Elevators (Mumbai), Hephzi Elevators (Bengaluru) and Global Elevators (Mumbai) are named here with their explicit consent. Record retention periods vary by jurisdiction and are not stated here as a single figure.
👉 Follow ElevatorPlus on,
Instagram LinkedIn Facebook YouTube Qoura Substack Twitter
