Data migration is the work of moving your firm’s records out of one system and into another so they arrive complete, correct, and usable, and for a commercial real estate firm the hard part is never the moving. It is the fifteen years of deal files you are moving. Every principal who has switched a CRM, adopted property-management software, or commissioned a custom tool has run into the same wall: the software is ready in a week, and the data takes two months. This is an explanation of what migration actually is, why a lean CRE firm’s archive is the difficult case, what it costs, where it goes wrong, and how to move the records without losing anything that matters.
What Data Migration Actually Means
Strip away the IT vocabulary and data migration is a move. You are taking the information a firm has accumulated in one place and relocating it to another, with the promise that nothing important is lost, scrambled, or duplicated on the way. The old place might be a retiring CRM, a shared drive of folders, an accountant’s spreadsheet, or the inbox where a broker has quietly filed a decade of correspondence. The new place might be a proptech platform you just bought or a custom tool built for how your firm actually works.
Vendors describe this with a three-word phrase, extract, transform, load, and the phrase is accurate but hides the effort. Extract means pulling the records out of the old system, which is easy when they sit in a clean database and hard when they live in scanned PDFs. Transform means reshaping them to fit the new system, because no two tools store a lease or a contact the same way. Load means putting them into the new home and confirming they landed intact. For a large company with an IT department, this is a project run by specialists moving structured tables. For a small firm, it is usually one person, often the owner or an ops lead, staring at a folder tree nobody has organized since 2011.
The definition that matters for a firm your size is simpler. Migration is the step that decides whether switching tools improves your work or buries you. Do it well and the new system starts full and useful on day one. Do it badly and you spend a year working in two places at once, trusting neither. Getting this right is one of the unglamorous disciplines behind how a lean shop out-operates much larger, better-resourced firms: the small firm that keeps its records clean and portable moves faster than the giant drowning in its own systems.
Why 15 Years of Deal Files Is the Hard Case
Not all data is equal to move. A list of contacts in a spreadsheet migrates cheaply, because it is already structured: rows and columns a computer can read and remap in an afternoon. The reason CRE migrations run long is that the valuable half of a firm’s history is not structured at all. It is documents.
Fifteen years of deal files is a specific kind of mess, and naming it is the first honest step. There are signed leases, some typed and clean, many scanned as images from a fax or a phone camera, a few handwritten in the margins. There are letters of intent in a dozen formats, offering memoranda, rent rolls exported from three different accounting systems over the years, CAM reconciliations, estoppels, and property photos. There are spreadsheets that follow one broker’s private conventions and make sense only to that broker. There is a folder structure that grew by accident, with the same property filed three different ways, and there is email standing in as the real filing system, where the actual signed version of a document is an attachment someone sent in 2018.
A computer reads a clean spreadsheet effortlessly and a scanned lease not at all. Turning that scanned page into data means optical character recognition, and OCR quality on a crisp document is a saved hour, while OCR on a skewed, low-contrast scan is a confident wrong answer that takes longer to catch than a blank field. This split, structured records that move for pennies and documents that resist, is the entire cost driver of a CRE migration. When a proposal quotes a migration number, it is really quoting an estimate of how bad your documents are, and that is a number nobody can give without looking at the actual files.
The Anatomy of a Migration
However messy the source, a migration moves through the same five stages. Understanding them lets you tell a firm that knows what it is doing from one that is guessing.
Inventory. Before anything moves, someone counts what exists. How many contacts, how many properties, how many documents, in what formats, living in which systems. This unglamorous stage is where realistic timelines are born, because you cannot move what you have not counted, and the surprise that blows up a migration is always the pile of files nobody mentioned.
Mapping. Next, every field in the old world is matched to a field in the new one. The old CRM’s “Client Type” becomes the new system’s “Contact Category”; the spreadsheet column a broker labeled “$$” becomes an “Asking Rent” field. Mapping is where domain knowledge earns its keep, because only someone who understands CRE knows that two differently named columns hold the same fact, or that one column secretly holds two.
Extraction and transformation. With the map drawn, records come out of the old system and get reshaped to fit the new one. Structured data flows quickly here. Documents go through OCR and field extraction, and this is where the bulk of the effort and cost concentrates for a firm whose value lives in leases and agreements.
Loading. The reshaped records go into the new system. A careful migration loads a small test batch first, checks it, and only then moves the rest, rather than pushing fifteen years in one pass and hoping.
Verification. The final stage confirms the move worked: that counts match, that a sample of records is correct field by field, that no document was silently dropped. Skipping verification is the most common corner cut, and it is why some firms discover a year later that the 2019 leases never made it.
That connective work of matching one system’s fields to another is the same problem that makes your existing tools refuse to share data day to day. The mechanism behind both is worth understanding on its own, and it is laid out in a plain-English look at what an API is and why your tools talking to each other matters.
What Goes Wrong
Migrations fail in a handful of predictable ways, and every one of them is avoidable with attention.
The first is silent loss. Records that do not fit the new system’s assumptions get dropped without an error message, and because no alarm sounds, nobody notices until a specific lease is needed and is not there. The second is the confident-wrong-value problem, worse than loss because it hides. An OCR pass reads a rent of $4,200 as $42,000, or maps a renewal date into the wrong field, and the number looks perfectly plausible sitting in the new system. The third is duplication: the same contact arrives from the CRM, the spreadsheet, and the inbox, and the new system now holds three slightly different versions of one relationship.
A quieter failure is the two-system limbo, when a migration is declared done but staff keep checking the old system because they do not trust the new one. The firm now pays for both and works in neither cleanly. And the failure that turns a project sour is the unexamined pile: a migration scoped against the clean data everyone remembers, not the fifteen years of scanned documents nobody wanted to open, so the estimate was fiction from the start. Most of these trace back to skipping inventory or verification, the two stages with no visible output and the two that get cut when someone is in a hurry.
Where AI Helps and Where It Hurts
AI is genuinely useful in a migration, which is exactly why it needs a clear-eyed operator. The honest version is that a current-generation model is a strong assistant on messy documents and a dangerous one left unsupervised.
Where it helps is the document mountain. Modern AI tools read a scanned lease and pull out the tenant, the rent, the term, and the key dates far faster than a person retyping them, classify a folder of mixed files by document type, and flag likely duplicate contacts for review. For the part of a CRE migration that is otherwise pure manual labor, this is the real advance, and it is a large part of why custom AI automation for a real estate firm has become a practical rather than aspirational option.
Where it hurts is trust without checking. A model is only as reliable as the document beneath it, and it will produce a clean, wrong answer from a bad scan without hesitation. The failure is not that AI gets things wrong; it is that it gets them wrong confidently, so an unverified AI-driven migration can be faster and worse than a slow manual one. The discipline is to use the model to do the extraction and a human to verify a meaningful sample, especially on the money fields, the dates, and anything that would cause real damage if it were off. Deloitte’s 2026 commercial real estate outlook found that the firms getting value from AI treat it as an operational tool inside a disciplined process, not a replacement for judgment, and migration is a textbook case of that principle.
One more question sits underneath all of this: where do your confidential documents travel when a tool or an AI feature reads them? Deal terms and client financials are the sensitive core of the business, so before any file leaves your systems, get a plain answer on where it goes, who can see it, and whether it is retained. Treating that as a first-class question, not an afterthought, is part of the same posture covered in the anatomy of how a lean firm’s tech stack actually fits together.
What It Costs and How Long It Takes
Migration is a line item, never free, and the firms that get surprised are the ones who assumed the new tool included it. The cost is driven almost entirely by document volume and document quality, which is why an honest quote follows a look at your actual files rather than a price list.
For a small firm, migration usually arrives folded into one of two larger efforts. When you are switching proptech tools, migration is part of onboarding, and the vendor may do a basic import of structured records at no charge while treating your document archive as out of scope, which is the gap that catches firms off guard. When you are commissioning a custom tool, the migration and the cleanup are scoped inside the project. A well-run custom automation for a firm-specific workflow generally runs from roughly $25,000 to $150,000 in the open market depending on complexity and how messy the source data is, and a document-heavy migration is one of the factors that pushes a project up that range. Simply getting a team fluent enough to clean and organize its own data with AI assistance, rather than commissioning a build, is a training exercise that runs roughly $2,000 to $15,000.
Duration follows the same logic. Structured records move in days. A large, low-quality document archive can take weeks, because verification is human work and cannot be rushed without reintroducing the confident-wrong-value risk. The full arithmetic of when moving this data is worth it, versus staying where you are, sits inside the broader buy-versus-build decision, worked out in the playbook on when off-the-shelf proptech is enough.
How to Move the Files Without Losing Anything
A non-technical owner can run a migration well by insisting on a few things, none of which require knowing how the software works.
Start by counting. Demand an inventory of exactly what is being moved, in what formats and volumes, before anyone quotes a timeline, and make sure the fifteen years of documents are in that count, not just the tidy contact list. Keep the old system read-only and available for a defined period after cutover, so that if a 2017 lease surfaces missing, the original is still there. Move a test batch first and check it field by field before approving the full run. Verify by reconciling counts and spot-checking a real sample, paying closest attention to the fields that would cause damage if wrong: rents, dates, tenant names, entity ownership. And get the confidential-data answer in writing before any file leaves the building.
The deeper lesson is that a clean migration is a chance to stop the mess from re-forming. Fifteen years of scattered files became fifteen years of scattered files because no system connected the tools and no one owned the archive. If the new setup leaves those two conditions unchanged, you will be doing this again in five years. The connective problem underneath, why tools do not share data and a person becomes the bridge, is the recurring tax explained in a guide to what software integration actually is, and solving it is what keeps a migration from being a temporary reprieve.
Frequently Asked Questions
What is data migration in plain terms?
Data migration is moving a firm’s records out of one system and into another so they arrive complete, correct, and usable. For a commercial real estate firm that means relocating contacts, properties, leases, rent rolls, and correspondence from an old CRM, spreadsheets, shared drives, or email into a new proptech platform or a custom tool. The technical shorthand is extract, transform, load: pull the records out, reshape them to fit the new system, and load them in with a check that nothing was lost.
Why is migrating old deal files so hard?
Because most of a firm’s history is documents, not clean rows. Structured data like a contact list moves in a day. Fifteen years of leases, letters of intent, and rent rolls, many of them scanned images in inconsistent formats, must be read by optical character recognition and checked field by field, and OCR on a poor scan produces confident wrong answers. That document pile, not the moving itself, is what makes a CRE migration long and expensive.
How long does a data migration take for a small firm?
Structured records usually move in days. A large archive of scanned, inconsistent documents can take weeks, because verification is human work that cannot be safely rushed. The honest answer depends on the volume and quality of your documents, which is why a credible timeline follows an inventory of your actual files rather than a generic estimate.
How much does data migration cost?
It depends almost entirely on document volume and quality, so an honest quote follows a look at your files. When switching proptech tools, a vendor may import structured records as part of onboarding while treating your document archive as out of scope. When it is folded into a custom automation project, it is part of a build that generally runs from roughly $25,000 to $150,000 in the market depending on complexity and how messy the source data is. Getting a team fluent enough to clean its own data runs roughly $2,000 to $15,000.
Can AI do the migration for me?
AI is a strong assistant and a poor unsupervised operator. Current AI tools read scanned leases, pull out tenants, rents, terms, and dates, classify mixed files, and flag likely duplicates far faster than manual retyping. But a model is only as reliable as the document beneath it and will produce a clean, wrong value from a bad scan. Use AI to do the extraction and a person to verify a meaningful sample, especially the money fields and dates.
What is the difference between structured and unstructured data in a migration?
Structured data is already in rows and columns a computer can read directly, like a contact spreadsheet or a database export, and it moves cheaply. Unstructured data is documents: scanned leases, PDFs, letters, photos, and email attachments that hold their information as text or images rather than fields. Unstructured data must be read and extracted before it can be moved, and it is the source of nearly all migration cost and risk for a CRE firm.
What goes wrong in a data migration?
The common failures are silent loss (records dropped without an error), confident wrong values (an OCR pass reading $4,200 as $42,000, or mapping a date to the wrong field), duplication (the same contact arriving from three sources), and two-system limbo (staff keep using the old tool because they do not trust the new one). Almost all of these trace back to skipping the two stages with no visible output: counting the data first and verifying it after.
How do I make sure nothing is lost when we switch systems?
Insist on an inventory of exactly what is being moved before anyone quotes a timeline, and confirm the old documents are counted, not just the clean contact list. Keep the old system read-only and available for a defined period after cutover. Move a test batch and check it before the full run. Verify by reconciling counts and spot-checking a real sample of records, focusing on rents, dates, tenant names, and ownership. Get a written answer on where confidential files travel before any of them leave your systems.
Should the vendor handle migration or should I?
Make the vendor own as much as possible, but read the scope carefully. Many proptech vendors import structured records for free and quietly exclude your document archive, which is the expensive part. Whoever runs it, apply the same checks: an inventory up front, a test batch, verification against the old system, and a clear plan for handling confidential documents. Migration is a line item to negotiate, never an afterthought to assume is included.
Where to Start
Data migration is the unglamorous step that decides whether a new tool helps or buries you, and for a CRE firm the difficulty lives in the fifteen years of documents, not the software. The firms that move well count their files first, treat the document pile honestly, use AI for the labor but a human for the verification, and refuse to let anyone quote a timeline before looking at the actual mess.
The first move is not a purchase or a migration. It is an honest read of what you are sitting on and whether it is worth moving at all. A free AI-readiness assessment gives you that read: a short working session that looks at where your records live, how tangled the archive really is, and what it would take to move or clean it, then returns a plain recommendation rather than a sales pitch. Book a free AI-readiness assessment before you sign the next onboarding contract.
Dirk Jan van Veen, PhD
