> ## Documentation Index > Fetch the complete documentation index at: https://docs.dualentry.com/llms.txt > Use this file to discover all available pages before exploring further. # Migration Data Scope: What Moves and What Does Not > Reference for what a DualEntry migration brings across from QuickBooks or Xero, what you recreate by hand, and what arrives through an ongoing connector. A DualEntry migration pulls historical data from QuickBooks or Xero into your ledger through mapping steps and a Data Sync step. This page states exactly what that covers, what it does not, and which gaps an ongoing [integration](../integrations/index) fills instead of the migration. Scope differs by source system. Where a row below applies to only one source, it says so. ## Transactions that migrate The migration imports transactional records in dependency order, after accounts and classifications are mapped. Each source record becomes a DualEntry record of a mapped type, visible on the Data Sync step with a link to both the source record and the DualEntry record it created. The table below lists the source record types each connector imports. | Source system | Record types imported | | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | QuickBooks | Bills, bill payments, invoices, customer payments, credit memos, vendor credits, refunds, deposits, purchases, credit card transactions, sales receipts, bank transfers, journal entries | | Xero | Invoices, payments, credit notes, receipts, bank transactions, bank transfers, purchase orders, journals, manual journals | These land as the equivalent DualEntry record rather than as summary journal entries, so a migrated bill is a bill, with its vendor, lines, and open balance intact. On the Data Sync step you can convert an individual source record into any of the DualEntry transaction types by hand when the automatic mapping picked the wrong one. ## Master data that migrates Master data imports before transactions, because a transaction cannot be created until the records it references exist. The table below lists what migrates and any conditions on the import. | Data | QuickBooks | Xero | Notes | | ------------------------------------------------ | ---------- | ---- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Chart of accounts | Yes | Yes | Mapped account by account on the Accounts Mapping step. Accounts with no transaction history can be skipped so they do not clutter your new chart. | | Classifications (classes, departments, projects) | Yes | Yes | Each gets its own mapping step. Map or skip each value. | | Customers | Yes | Yes | Xero imports these as contacts. | | Vendors | Yes | Yes | Xero imports these as contacts. | | Items | Yes | Yes | A full Data Sync is blocked until default income, expense, and COGS accounts are configured for items. | | Employees | No | Yes | | | Fixed assets | No | Yes | | DualEntry also creates fallback accounts for source lines that have no mappable account: `[QuickBooks] Default Expense`, `[QuickBooks] Default Income`, `[Xero] Default Income`, and `[Xero] Unpaid Expense Claims`. They appear on the Accounts Mapping step and can be mapped to a real account or deactivated, but never skipped. Treat a balance in one as a mapping gap to close before you [tie out](./validate-a-migration). ## Attachments Attachment behavior is the largest single difference between the two sources, and it is worth confirming before you cancel the old subscription. **Xero.** Source attachments migrate. Documents attached to Xero transactions are downloaded and attached to the corresponding DualEntry record, so invoice PDFs and receipts arrive with the transaction. **QuickBooks.** Attachments do not migrate. Migrated QuickBooks records arrive with no attachments at all. Plan either a separate export of QuickBooks attachments to upload individually to the corresponding DualEntry records, or continued read-only access to QuickBooks for historical source documents. Which you choose usually depends on your audit cycle. If an auditor will ask for supporting documents on migrated transactions, export them and attach them in DualEntry, where each record holds up to 25 files of 10 MB each. If the migrated periods are already audited and closed, read-only access to the old system is normally enough. Attachments you add later can go on through [OCR document upload](../ai-automation/ocr-document-upload) or on the record itself. Export attachments and historical reports from the source system before the subscription lapses. A migration does not retrieve them later, and for QuickBooks it never had them. ## What does not migrate These are out of scope by design. Each needs a decision during [cutover](./migration-cutover-runbook) rather than a workaround afterwards. * **Historical revenue recognition schedules.** In-flight contracts are recreated in DualEntry using the cutover date and accumulated revenue fields, which preserve total contract value while generating entries only from cutover forward. See [migrate mid-life contracts](../revenue-recognition/migrate-mid-life-contracts). * **Prepaid and fixed asset amortization schedules.** Recreate these as [amortization schedules](../core-financials/prepaid-expense-amortization) or [fixed assets](../core-financials/fixed-asset-management), using the catch-up fields to carry accumulated balances rather than re-amortizing from the start. * **Reconciliation history.** Bank reconciliations completed in the old system do not carry over. Migrated bank transactions arrive unreconciled and reconcile forward in DualEntry. * **Approval history.** Which person approved a bill in the source system is not imported. The DualEntry [audit trail](../platform-configuration/audit-trail-and-compliance) starts at migration. * **Budgets, saved reports, and report layouts.** Rebuild these in the [custom report builder](../reporting-analytics/custom-report-builder) and [budgeting](../platform-configuration/budgeting-and-forecasting). * **Users, roles, and permissions.** Configure these in DualEntry under **Configuration → Company**. * **Payroll detail.** Payroll arrives as journal entries from a [payroll integration](../integrations/index) going forward rather than as migrated payroll runs. ## What arrives through a connector instead Some data is deliberately not part of the migration because an ongoing integration is the better source for it. Connect these during cutover so there is no gap between the last migrated day and the first connected day. The table below lists each data type and where to set up the connection. | Data | Where it comes from | Reference | | ----------------------------------------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------ | | Bank and credit card transactions after cutover | A bank feed, refreshed continuously | [Bank connections](../core-financials/cash-management/bank-connections) | | Payroll journal entries | Your payroll provider | [Gusto](../integrations/gusto), [Rippling](../integrations/rippling), [ADP](../integrations/adp) | | Spend and card transactions | Your card provider | [Ramp](../integrations/ramp), [Brex](../integrations/brex) | | Billing and revenue data | Your billing system | [Stripe](../integrations/stripe), [Chargebee](../integrations/chargebee) | | AP workflow and payments | Your AP platform | [Bill.com](../integrations/bill-com) | A connector and a migration can both point at the same source system for a period. Confirm the connector's cutoff date so it does not re-import transactions the migration already brought across. ## Source systems supported The migration supports **QuickBooks** and **Xero** as source systems, chosen when you start a migration for a company. The source picker also carries a request link for systems that are not listed. Each migration connects one DualEntry company to one source organization. A multi-entity group runs one migration per legal entity, each with its own credentials and its own mapping, and the Migrations overview separates single-entity from multi-entity migrations so you can see which companies are still unconnected. Moving from a system without a migration connector is a manual exercise built on [bulk import](../integrations/bulk-import) rather than the Migrations page. You export from the source, map columns to DualEntry fields, and load master data and transactions as files, which means you own the account mapping and the balancing that the Migrations page would otherwise handle. For NetSuite specifically, see [migrating from NetSuite](./from-netsuite), which covers the export and import path and the mapping decisions that differ. The tie-out and cutover guidance on the rest of these pages applies either way: the evidence a controller needs does not change with the loading mechanism. ## Related reading * [How to Run a Migration Cutover](./migration-cutover-runbook) * [How to Validate and Tie Out a Migration](./validate-a-migration) * [Migration Failure Modes and Recovery](./migration-failure-modes) * [Data Handling During a Migration](./migration-data-handling) * [Migrating from QuickBooks or Xero](./from-quickbooks-xero) * [Migrate Mid-Life Contracts](../revenue-recognition/migrate-mid-life-contracts) * [Bulk Import: Load Records from a File](../integrations/bulk-import)