Two facts frame everything below.

There is no portable format. MITS, the multifamily data standard, defines how two running systems exchange messages. It is not a migration format, adoption is voluntary, and no manufactured housing profile exists. OSCRE's data model standardises definitions, not exports. Nothing in the industry defines a portable resident, lease and ledger file you can hand from one vendor to another.

And no US law gives you a right to your own data back. GDPR-style portability applies to individuals, not to businesses. Your exit rights are whatever your contract says — and if the contract is silent, that is the answer.

This article covers what actually migrates, what silently does not, why manufactured housing is a harder case than multifamily, and what to establish before you sign anything.

Key takeaways

• No data standard exists for system-to-system migration. MITS governs message exchange between live systems; adoption is voluntary.
• No US law grants a business customer data portability. GDPR Article 20 confers the right on a natural person, not a company.
• Standish Group's CHAOS 2015 report found 29% of projects successful, 52% challenged, 19% failed across roughly 25,000 projects.
• Project size is the strongest predictor: small projects 61% successful and 7% failed; grand projects 6% successful and 43% failed.
• McKinsey and Oxford found large IT projects ran 45% over budget and delivered 56% less value than predicted (published October 2012).
• Manufactured housing has two objects — homesite and home — where generic systems have one. No published source discusses this problem.
• Home identity data is federally mandated under 24 CFR 3280.5 and has no equivalent field in an apartment system.

What is a property management system migration?

A migration is the transfer of operational records — residents, leases, ledgers, balances, deposits, work orders, vendors and documents — from one property management system into another, so that the new system opens with the same financial position the old one closed with.

It is not a data export. An export produces files. A migration produces a working system whose balances reconcile, whose history is queryable, and whose users can do their jobs on Monday.

The distinction matters because most vendor conversations are about the first and most project failures happen in the second.

Is there a data standard for moving between systems?

No. And the standard people cite when they think there is one does something different.

MITS — the Multifamily Information and Transactions Standards — was established in 2002 by the National Multi Housing Council and is now maintained by RETTC, an affiliate of the National Multifamily Housing Council launched at the October 2024 OPTECH conference.

The current MITS models include Core Data 4.0, Resident Transactions 3.0, Lease/Application 3.0, Resident Screening 3.0 and Property-Marketing/ILS 5.0. But read the stated scope: data transmission among software systems "is facilitated through Application Programming Interfaces (APIs) and Extensible Markup Language (XML)."

That is integration between running systems, not migration between them. MITS tells two live systems how to pass a message. It does not define a file that carries your book of business out of one vendor and into another.

Adoption is also optional. RETTC states plainly, in a release dated 14 January 2025, that "the adoption of MITS is voluntary on the part of rental housing providers."

OSCRE International publishes an open Industry Data Model covering 130+ use cases, standardising what terms mean across real estate. Also not a migration format.

And no manufactured housing profile exists in either. Neither standard has fields for a home serial number, a HUD certification label, a lienholder, or a lot-rent-versus-home-rent split.

What data actually has to move?

Seven categories, in rough order of how badly things break if they are wrong.

1. Ledgers and balances — what each resident owes, as of the cutover date
2. Leases — terms, rent, escalations, expiry, renewal position
3. Residents — identity, contact, tenancy start, occupants
4. Security deposits — amounts held, and where
5. Recurring charges — pass-throughs, utility charges, fees
6. Vendors and payables — open items and payment history
7. Documents — signed leases, addenda, ID scans, inspection photos, notes

No neutral body publishes a migration checklist. Not a regulator, not an association, not an accounting body. Every list available, including this one, derives from vendor guidance or reasoning. That absence is worth knowing when a vendor tells you what is "standard."

The financial reconciliation is the part with an external standard attached, and it comes from audit practice rather than software practice: closing balances on the old system at the migration point must equal opening balances on the new one, with the retained earnings check first, supported by a documented set of mapping rules the auditors can review.

Two valid approaches exist: carry every transaction up to the migration date, or carry closing balances only. Both are defensible. Choosing neither, and ending up with partial history, is the failure mode.

What gets left behind, and why?

Three categories disappear routinely, and one of them disappears silently.

Historical financial data is often dropped because per-record storage costs, import time and destination performance all scale with it. This is a deliberate decision and usually a defensible one — but it should be a decision, made with a stated cut-off year, not a discovery.

Attachments are the silent loss. Documents typically live in a separate file storage layer from the records they belong to. Migrate the records without mapping the file associations and the files may survive while their connection to the resident does not. As one vendor migration guide puts it, data in custom fields "can disappear if nobody plans for it."

Custom fields with no native counterpart in the destination system are the third. And in manufactured housing, this is not an edge case — it is where your most important data lives, for reasons covered next.

Practical instruction: before signing, ask for a written statement of what will not be migrated, with reasons. A vendor who can produce that quickly has done this before.

What makes manufactured housing migration different?

Manufactured housing has two objects where conventional property management systems have one.

A generic system models a unit — a space with a lease and a tenant. A manufactured housing community has a homesite, which carries the lot lease, lot rent, utility recovery and occupancy history, and a home, which carries what it is, what condition it is in, and who owns it.

Those two things are separately owned, separately valued, separately taxed and separately financed. A resident can own the home while leasing the site. The community can own both. The site can be occupied by a home that produces no revenue at all.

We searched for published discussion of this data-model conflict and found none. No standards body, no association, no research firm, no academic source addresses it. Every result was vendor marketing. The industry's central data-modelling problem is undocumented outside sales copy — which is itself the finding, and the reason this migration is harder than a vendor demo suggests.

The fields with no home in an apartment system

Home identity is federally mandated. 24 CFR §3280.5 requires each home's data plate to carry the manufacturing plant, "the serial number and model designation of the unit, and the date the unit was manufactured," a list of certification label numbers, factory-installed equipment, and the roof load and wind load zones the home was designed for.

None of that describes a rental unit. All of it has to go somewhere.

Title and lienholder are separate legal objects from the land. Freddie Mac's titling fact sheet, dated October 2025, groups states into non-certificate-of-title, certificate-of-title, and title-surrender categories, and notes that "the lien on the land and the manufactured home need to be properly created, evidenced, and perfected."

And this is not a minority case. The CFPB reported, from 2019 HMDA data, that "around 42 percent of manufactured housing loans are chattel loans, which are loans secured by the home but not the land." A system with nowhere to record a lienholder against a home is missing a field that applies to roughly two in five financed homes.

Four more MH-specific structures a unit model cannot express:

• Park-owned versus tenant-owned status, which determines whether the revenue line is lot rent alone or lot rent plus home rent — a distinction covered in the park-owned versus tenant-owned analysis
• The lot rent / home rent split, which lenders require reported separately
• Vacant homesite versus homesite occupied by a vacant home — physically different, economically different, and identical in a system with one occupancy flag
• Home inventory held for sale, which is neither a unit nor a lease

For scale on how much of this exists: a manufactured housing REIT's Q2 2026 operations update filed with the SEC reports 145 communities containing approximately 27,100 developed homesites, "of which 11,200 contain rental homes," at 95.3% rental occupancy. That is two counts, on two objects, in one sentence — and a single-object system cannot hold it.

How long does it take and what does it cost?

No independent benchmark exists for property management software implementation duration or cost. No association or research firm publishes one. Vendor guidance commonly cites 90 to 120 days from kickoff to a validated close — treat that as a vendor claim, not a benchmark.

What is independently measured is the wider category, and it is sobering.

Bloor Research reported in September 2007 that "more than 60% of data migration projects have overruns on time and/or budget." Nearly two decades old, frequently quoted as current, and worth dating when you cite it.

McKinsey, with the University of Oxford, studied more than 5,400 large IT projects and found they ran 45% over budget and 7% over schedule while delivering 56% less value than predicted. Every additional year on a project increased cost overruns by 15%. And 17% of projects "go so bad that they can threaten the very existence of the company." Published October 2012.

Budget for a range rather than a date, and treat any quoted go-live as the earliest plausible one.

Why do these projects fail?

Size is the single strongest predictor, and it points to a specific strategy.

The Standish Group's CHAOS Report 2015, covering roughly 25,000 projects across five years, found overall resolution of 29% successful, 52% challenged and 19% failed. Broken down by project size:

Note: the CHAOS methodology is contested in academic literature. Read the gradient rather than the precise percentages.

The instruction that falls out of this is unambiguous: migrate one community first, not the portfolio. A small project succeeds 61% of the time and fails 7%. A grand project succeeds 6% and fails 43%. Nothing else in this article moves the odds that far.

On causes, Standish weights executive sponsorship, emotional maturity, user involvement and optimisation at 15% each — four factors that are all about people, not software.

McKinsey attributes roughly half of overrun cost to unclear objectives and late stakeholder alignment, illustrated by a line worth pinning up: "Finance department became involved only a few months before the system was due to go live."

And on data quality specifically, Gartner research from 2020 put the average cost of poor data quality at $12.9 million a year per organisation. You are not migrating clean data. Nobody is.

Do you own your data? Can you get it back?

Legally, in the US, you have no statutory right to it. Contractually, you have whatever you negotiated.

There is no federal or state law granting a business customer portability of its operational data from a SaaS vendor. GDPR Article 20 — the provision usually invoked — confers the right on "the data subject," a natural person. It does not give a company a right to its own resident ledgers.

California's CCPA business-to-business exemption expired on 1 January 2023, bringing B2B contact information into scope — but those rights still belong to individual California residents, not to a business seeking its own records.

So the contract is the whole of it. The American Bar Association's Business Law Today guidance on SaaS agreements, published November 2021, sets out what should be in yours:

• Confirmation that "the customer owns its data" and all related intellectual property rights
• That "upon termination of the agreement the customer may take its data to a new cloud provider"
• A description of "how and in what format the data will be returned to the customer"

That third clause is the one that gets omitted, and it is the one that matters. "You may export your data" means nothing if the export is a PDF of screens. Ask for the format, in writing, before you sign.

Should you run both systems in parallel?

Parallel running is the lowest-risk approach and the most expensive one, and it has a defined failure state.

The costs are real: two sets of licensing, support and hosting; staff entering transactions twice; and reconciliation differences that are slow to investigate. The rule that matters: parallel running indefinitely is a failure state, not a safety net. If nobody has set a date to switch off the old system, the project has not finished — it has stopped.

From the audit side, the requirement is narrower and clearer. Closing balances on the old system must equal opening balances on the new one, the retained earnings check comes first, and the auditors need documented mapping rules explaining where each balance and transaction now lives.

If you run parallel, set the shutdown date before you start, and treat the reconciliation — not the go-live — as the completion milestone. The accounting side of that reconciliation is set out in the manufactured housing accounting guide.

What to ask before you sign

Ten questions. The first five are about data, the last five about the project.

1. What exactly will not be migrated, and why? In writing.
2. How far back does ledger history come? Name the year.
3. How are documents and their record associations handled?
4. Where do home records go — serial, HUD label, title, lienholder, POH/TOH status?
5. On termination, what format is my data returned in? Not whether — what format.
6. Who is accountable on your side, and are they the person in this room?
7. When does our finance lead get involved? If the answer is near go-live, that is the McKinsey failure pattern.
8. Can we start with one community? The size gradient says you should.
9. What is the reconciliation plan — closing to opening, with mapping rules?
10. What is the date we switch the old system off?

Questions four and five are the ones a generic vendor will struggle with, and they are the ones that separate a system that models manufactured housing from one that models apartments with the labels changed. The broader evaluation framework sits in the software buyer's guide.

How RIOO fits

RIOO is a property management platform built natively on Oracle NetSuite, and it models the homesite and the home as two records rather than one unit.

That matters at migration specifically, because the fields that have nowhere to go in a generic system — serial number, HUD certification label, title and lienholder, park-owned versus tenant-owned status, lot rent separate from home rent — have a defined destination rather than a custom field that may or may not survive.

Because the accounting is native NetSuite rather than a bolt-on ledger, the closing-to-opening balance reconciliation an auditor will ask for runs in the same system as the operational data, rather than across two.

See how RIOO handles manufactured housing communities.

Conclusion

The honest position on switching systems is that the industry has made it harder than it needs to be. There is no portable format, no legal right to your own records, and no published guidance on the one data-model problem that defines manufactured housing.

What you can control is scope and sequence. Migrate one community, not a portfolio — the difference between a 61% and a 6% success rate is not a rounding error. Get the finance lead involved at the start rather than the end. Establish where home records go before you sign, and what format your data comes back in when you leave.

Everything else is negotiable. Those four are not.

Frequently asked questions

Q1. Is there a standard format for moving between property management systems?
No. MITS, maintained by RETTC, standardises message exchange between running systems via APIs and XML, and its adoption is voluntary. OSCRE's Industry Data Model standardises definitions. Neither defines a portable export of residents, leases and ledgers, and neither has a manufactured housing profile.

Q2. Do I legally own my data in a SaaS property management system?
There is no US law granting a business customer data portability. GDPR Article 20 applies to natural persons, not companies. Your rights are entirely contractual, so the agreement should confirm you own the data, that you may take it to a new provider on termination, and specifically what format it will be returned in.

Q3. How long does a property management software migration take?
No independent benchmark exists. Vendors commonly cite 90 to 120 days. For context, McKinsey and Oxford found large IT projects ran 45% over budget and 7% over schedule, and Bloor Research found more than 60% of data migration projects overran on time or budget.

Q4. Why is manufactured housing migration harder than apartments?
Because manufactured housing has two objects — the homesite and the home — where a conventional system has one unit. Home serial numbers, HUD certification labels, title and lienholder records, park-owned versus tenant-owned status and the lot-rent-versus-home-rent split have no native fields in a system built for apartments.

Q5. What usually gets lost in a migration?
Historical financial data beyond a chosen cut-off, document attachments whose association to the resident record is not mapped, and custom fields with no counterpart in the destination system. In manufactured housing, that last category is where home data typically sits.

Q6. Should I migrate everything at once?
The evidence says no. Standish Group data shows small projects succeed 61% of the time and fail 7%, while the largest projects succeed 6% and fail 43%. Migrating one community first is the single largest improvement available to your odds.