Ask any operations or finance leader at a real estate company what worries them most about switching to a new ERP, and you'll hear the same answer almost every time: the data migration.
The concern is valid. Real estate data isn't like typical business data. It's relational, time-sensitive, and legally significant. A lease isn't just a record- it's a contract with compounding obligations. A tenant isn't just a contact- they're linked to invoices, payments, deposits, correspondence, and possibly litigation history. One wrong mapping decision and your go-live is a liability.
A standard ERP migration for a product or services company typically involves customers, vendors, items, and open invoices- a finite set of objects with well-defined relationships. Real estate migrations are structurally more demanding, and understanding why is essential to planning at the appropriate level of rigor.
In real estate, almost every record points to another. A unit belongs to a building which belongs to a property which may belong to a portfolio. A lease references a unit, a tenant, a legal entity, a start date, an end date, escalation clauses, security deposit terms, and renewal options. A tenant has open balances, prepaid rent, deferred revenue, and potentially multiple active leases across different properties.
Any break in that chain during import results in unlinked records, inaccurate aging reports, or incorrect financial statements from the first day of operation.
Unlike most industries, real estate carries specific accounting treatments that need to be established correctly in NetSuite before data can be imported. These include:
Each of these requires the right account structure, subsidiary setup, and reporting dimensions to be in place before historical data is loaded. The sequence matters as much as the content.
Real estate companies operate in a regulated environment. Auditors will ask for the history behind your opening balances. Tenants will dispute charges based on lease terms. Your data migration is not simply an IT project- it is an accounting event that must be defensible. That means maintaining source documentation, keeping migration logs, and ensuring your opening entries are reconcilable to your legacy system's final trial balance.
Real estate migrations demand more than data transfer- they require a system capable of preserving complex relationships, financial logic, and audit integrity from day one.
This is where a platform built for configurable data structures and multi-entity accounting becomes essential.
NetSuite’s architecture- with its flexible record types, native CSV import engine, and SuiteScript extensibility- is well-suited to accommodate complex real estate data structures. What it requires in return is a disciplined, sequenced approach to migration planning.
Real estate migrations become manageable when the full scope is broken into discrete data domains. There are six primary categories, each with a distinct migration approach.
The foundational layer. Each property is typically a Location record in NetSuite, carrying address, property type, ownership entity, acquisition date, and net rentable area. All lease and unit records anchor to this layer — it must be in place before anything else is imported.
Individual leasable spaces — suites, apartments, retail bays, parking stalls — are typically child records of a property. Each unit carries its own attributes: square footage, unit number, floor, current occupancy status, and market rent. In a multi-tenant commercial build, units feed directly into occupancy reporting and rent roll generation.
Tenants are Customer records in NetSuite, linked to a specific subsidiary and carrying contact information, credit details, and internal entity classification (individual, corporate, government). This is also where billing preferences, tax categories, and communication history are associated if notes or service requests are being migrated.
Leases are the most structurally complex records in a real estate migration. Each active lease must carry: the unit reference, tenant reference, lease type, commencement and expiration dates, base rent amount, rent escalation schedule, security deposit amount, CAM contribution structure, renewal options, and lease status. Historical expired leases may also require migration if they carry unresolved financial obligations or are referenced in tenant history reports.
The chart of accounts should be established in NetSuite first — modelled from the prior system with adjustments for NetSuite's segmentation dimensions (subsidiary, department, location, class). Once accounts are live, opening balances are entered via journal entry as of the cutover date, reconciled to the legacy system's final close.
This is the category that generates the most debate during planning. How many years of history do you bring over? The answer depends on audit requirements, reporting needs, and appetite for migration effort. At minimum, you need 12–24 months of transactions for meaningful trend analysis. Some organizations choose to archive older history in read-only form rather than migrate it fully into NetSuite. Either approach is defensible as long as it's documented.
Data mapping is the process of defining — field by field — how your legacy system's data corresponds to NetSuite's data model. It is detailed, methodical work, and it is what separates clean migrations from those that require years of post-go-live remediation.
Below are the core mapping tables for the primary record types.
| Legacy Field | NetSuite Field | Record Type | Notes |
|---|---|---|---|
| Property Name | Name | Location | Must be unique per subsidiary |
| Property Code / ID | External ID | Location | Use legacy ID to preserve references |
| Address (Street, City, State, Zip) | Address fields | Location | NetSuite uses structured address format |
| Property Type (Office, Retail, Residential) | Custom Field or Class | Location | Use a custom dropdown list |
| Owning Entity | Subsidiary | Location | Must match subsidiary structure |
| Net Rentable Area (SF) | Custom Field | Location | Required for occupancy calculations |
| Acquisition Date | Custom Field | Location | Use date field type |
| Legacy Field | NetSuite Field | Record Type | Notes |
|---|---|---|---|
| Tenant Name | Company Name / Individual Name | Customer | Distinguish entity vs. individual |
| Tenant ID / Code | External ID | Customer | Critical for lease reference linking |
| Contact Name | Contact (child record) | Contact | Create as child of Customer |
| Email / Phone | Email / Phone | Customer / Contact | Verify primary contact designation |
| Tax ID / SSN | Tax ID Number | Customer | Controlled access; verify permissions |
| Billing Address | Billing Address | Customer | May differ from unit address |
| Tenant Category | Customer Category | Customer | Create matching categories in NetSuite first |
| Assigned Property | Location | Customer | Link to property Location record |
| Legacy Field | NetSuite Field | Notes |
|---|---|---|
| Lease Number | External ID / Name | Unique identifier — never duplicate |
| Tenant Reference | Customer (lookup) | Match via External ID |
| Unit / Suite | Unit Custom Record or Location | Depends on implementation model |
| Lease Start Date | Commencement Date | Format as MM/DD/YYYY in CSV |
| Lease End Date | Expiration Date | Record natural end date, not option periods |
| Monthly Base Rent | Rent Amount | Base amount only; escalations are separate |
| Escalation Schedule | Custom Sublists / Child Records | Each escalation row = child record |
| Security Deposit Amount | Custom Field | Also post as liability journal entry |
| Lease Status | Status Field | Use consistent values: Active / Expired / Terminated |
| Lease Type | Custom Dropdown | E.g., Gross, NNN, Modified Gross, MTM |
The quality of a migration output is directly determined by the quality of the source data. If you are planning to migrate to NetSuite property management, a thoroughly audited source dataset is the single most impactful investment you can make before the project begins. Most legacy property management systems carry years of accumulated inconsistencies - duplicate tenant records, expired leases that were never formally closed, units with incorrect square footage, and billing addresses that have not been maintained. Migration creates a structured opportunity to resolve all of it.
Approach data clean-up as a structured audit. Below are the essential tasks for each major data category:
NetSuite's native CSV import tool (accessible via Setup → Import/Export → Import CSV Records) is a reliable, well-documented data ingestion mechanism. Understanding the field formatting conventions it requires prevents the majority of import failures before they occur.
NetSuite imports data in a mapped template model. You upload a CSV, then field-map each column to a NetSuite field using an on-screen interface. The mapping can be saved as a template for repeated imports. The system validates each row and returns a log showing which records succeeded, which failed, and why.
NetSuite supports CSV imports for:
Customers, Contacts, Locations, Vendors, Employees, Journal Entries, Invoices, Customer Payments, Custom Records, and Chart of Accounts.
Records must be imported in dependency order. A lease cannot be imported before its referenced tenant and unit exist. The correct sequence is:
NetSuite's CSV import includes a Run Validation option- always use it before executing a real import. It checks all rows for errors without writing any data to the database, and returns a result log showing exactly what would fail and why. Fix all errors before running live. For large imports, consider using SuiteScript or NetSuite's SuiteTalk Web Services API for higher throughput and better error handling.
Opening balance accuracy is where a migration's credibility is established or undermined. Your opening balances in NetSuite must agree, to the penny, with your legacy system's final closed balance. Auditors will verify this. Finance
leadership will reference it. The AR team will rely on it every time a tenant raises a billing dispute.
Option A - Summary Journal Entry
Post a single journal entry with net balances by account as of cutover date. Fast to implement, harder to reconcile at the tenant level. Best for companies with clean, simple tenant ledgers.
Option B - Open Invoice Import
Import each open invoice and bill individually, then offset with an opening balance journal. Gives full tenant-level detail. Required if tenants need to see itemized balance history from day one.
Most real estate companies choose a hybrid: Option B for AR (tenant-level detail matters too much) and Option A for other balance sheet accounts where the total is more important than the line-item breakdown.
Leases are simultaneously the most important and the most technically complex records in a real estate migration. Their accuracy determines whether the system functions as an operational property management platform or operates simply as a general ledger with property reporting layered on top.
As a general framework:
Escalation schedules are where most lease migrations encounter problems. A five-year commercial lease may carry four escalation dates, each with its own rent amount, effective date, and potentially a different CAM contribution percentage. Each escalation step must exist as a child record of the parent lease, imported in sequence after the parent lease record is established.
In the CSV template, model escalations as separate rows with the parent Lease External ID as the linking field. Import the parent lease file first, confirm successful import, then import the escalation child records.
For commercial leases with CAM reconciliation, the migration must capture the monthly CAM estimate, the reconciliation cadence (typically annual), any applicable expense cap, and the tenant's proportionate share percentage. These fields drive year-end reconciliation billing — one of the most frequent sources of tenant disputes when incorrectly configured.
Option periods — renewal options, expansion rights, termination options — should be captured as structured data fields, not stored in free-text notes. They carry future financial implications that require proactive tracking. For each option type, record: option type, exercise window start date, exercise window end date, option rent or escalation method, and current status (unexercised / exercised / expired).
For tenants with extended histories, the decision of how much transaction-level detail to migrate versus summarise as an opening balance requires deliberate planning. The minimum requirement is all open (unpaid) invoices. Where the timeline and budget allow, 24 months of transaction history provides sufficient depth for the operations team to address tenant payment enquiries without accessing the legacy system.
The go-live strategy is the culmination of every prior migration decision. There are two primary approaches, each with distinct trade-offs.
Parallel Run Both systems operate simultaneously for a defined period — typically one to three billing cycles. Transactions are entered in both systems and outputs are compared. This approach provides a high degree of confidence but doubles the operational workload and can introduce confusion when the two systems produce minor variances due to rounding or timing differences.
Hard Cutover The legacy system closes on a defined date and NetSuite goes live the following day. This eliminates duplication and reduces cost, but requires a high degree of confidence in migration quality and data accuracy before the switch is made.
For most real estate companies, a modified hard cutover is the most practical approach: close the legacy system at month-end, complete the final trial balance reconciliation, load opening balances into NetSuite, and go live at the start of the new period.
The following errors appear consistently across real estate NetSuite migrations. Each is avoidable when identified and addressed during the planning phase.
1. Skipping the Subsidiary and Account Structure Review- Teams that begin importing data before the foundational architecture is confirmed consistently encounter structural errors that require significant remediation. If the subsidiary configuration is incorrect, every record linked to it is affected. If the chart of accounts does not align with reporting requirements, restructuring after go-live is resource-intensive. The GL structure should be fully confirmed — with sign-off from the CFO and accounting team — before any import activity begins.
2. Using Names Instead of External IDs for Cross-Record References- Tenant names and property names change over time, and naming conventions are often applied inconsistently across legacy systems. If a lease CSV references tenants by name rather than External ID, a single variation — "Smith Holdings LLC" vs "Smith Holdings, LLC" — will cause the import to fail. All cross-record references should be mapped via External ID exclusively, established at the start of the project and maintained consistently across every import file.
3. Migrating Excessive Historical Data Without a Defined Scope- There is a natural tendency to migrate as much historical data as possible. In practice, migrating three years of transaction history significantly extends the timeline, increases cost, and often produces data that operations teams rarely reference. Establishing a clear cutoff date, migrating what is required for operations and compliance, and archiving the remainder in the legacy system or a document repository is the more effective approach.
4. Not Reconciling Opening Balances Before Going Live- Opening balance journal entries are where migrations most commonly introduce errors that take six to twelve months to surface fully. A deferred revenue account that is off by a material amount, or a security deposit liability that does not reconcile to the deposit register, will compound over time. Before go-live, the NetSuite trial balance must agree to the legacy final close, and that reconciliation must be signed off by a finance leader — not delegated to the project team alone.
5. Underestimating User Training as a Migration Requirement- A correctly migrated dataset within a system that the operations team does not know how to use is a failed implementation. User training is not a post-migration activity — it is an integral component of the migration programme itself. Property managers, finance staff, and reporting users need to be proficient in NetSuite before go-live. Delayed training results in workarounds, incorrect data entry, and a prolonged period of reduced operational efficiency after the system is live.
Migrating to NetSuite is one of the most complex- and most consequential- transitions a real estate company can undertake. When executed with discipline, it results in clean data, defensible audit trails, real-time financial visibility, and a scalable foundation for long-term portfolio growth. Successful migrations consistently demonstrate that planning quality determines go-live quality. A structured data audit, properly designed subsidiary and GL architecture, disciplined field mapping, and precise opening balance reconciliation are not technical formalities- they are strategic control points that shape operational performance from day one.
For real estate organisations, an additional consideration is that NetSuite is a general-purpose ERP and does not natively include constructs such as lease records, rent roll views, or CAM reconciliation workflows. Most implementations address this through structured configuration, SuiteSuccess methodology, or a native real estate extension layer. RIOO, built on NetSuite, provides pre-configured real estate data models within the same environment, reducing both migration complexity and ongoing configuration effort. Regardless of the approach, the disciplined migration framework outlined in this guide remains the foundation of a successful transition.
How long does a NetSuite data migration typically take for a real estate company?
For a portfolio of 10–30 properties, expect 3–6 months from kickoff to go-live. Larger or multi-entity portfolios can take 6–12 months. The primary timeline driver is the condition and completeness of source data before the project begins.
What is the best cutover date for a real estate NetSuite migration?
Fiscal year-end is the most straightforward option — the books are already closing, the trial balance is under audit, and the NetSuite opening entry aligns to a natural financial boundary. If year-end is not feasible, a month-end cutover is the preferred alternative. Mid-month cutovers create a split accounting period that must be reconciled across two systems and should be avoided where possible.
How do I handle ASC 842 lease accounting during a NetSuite migration?
The present value of remaining lease payments for each active lease must be calculated as of the cutover date, ROU asset and lease liability accounts established in the NetSuite chart of accounts, and initial recognition journal entries posted as part of the opening balance setup. These entries are the most audit-sensitive items in the migration and should be prepared with direct input from the accounting team.
What happens if migration data is found to be incorrect after go-live?
Post-migration corrections fall into three categories: incorrect opening balance amounts (addressed via adjusting journal entries), missing or incorrectly mapped records (addressed via re-import in Update mode), and structural issues such as incorrect subsidiary assignment (addressed via manual correction and the most time-consuming to resolve). Identifying and resolving errors during pre-import validation is always faster and less costly than post-go-live remediation