Chapter 11.1

Migration Strategy

Before extracting a single record, establish a clear strategy that defines what you're migrating, how much history to bring, and what your success criteria are.

The Three Migration Questions

Every migration strategy must answer these fundamental questions:

1. What Data to Migrate?

Not all data deserves to move to the new system. For each data type, ask:

  • Is this data still relevant to ongoing business operations?
  • Is it required for regulatory or audit purposes?
  • Does it have business value that justifies the migration effort?
  • Can it be recreated if needed, or is it irreplaceable?

2. How Much History?

Historical data migration is often the most time-consuming part. Consider:

  • Open transactions: Always migrate—open orders, unpaid invoices, outstanding POs
  • Recent history: Usually 1-3 years for reporting and trend analysis
  • Deep history: Archive in legacy system or data warehouse; don't migrate

3. What's the Cutover Approach?

How will you transition from old system to new?

  • Big Bang: Full cutover on go-live date; old system turned off
  • Parallel: Both systems run simultaneously for a period
  • Phased: Migrate different areas or entities at different times

Data Categories

Organize your migration by data category. Each has different characteristics and dependencies.

Category Examples Typical Approach Dependencies
Setup Data Chart of accounts, tax codes, payment terms Manual configuration or import None—migrate first
Master Data Customers, vendors, items, employees CSV import Setup data
Opening Balances GL balances, inventory, AR/AP aging Journal entries, inventory adjustments Master data, chart of accounts
Open Transactions Open sales orders, open POs, pending invoices CSV import or manual entry Master data
Historical Transactions Closed orders, paid invoices, historical data Summary journal entries or data warehouse All other data

Migration Scope Decision Framework

⚖️ Key Decision

Historical Data: Migrate or Archive?

🎯 Consultant Insight

The biggest mistake in data migration is trying to migrate everything. Challenge every request for historical data with: "How often will you actually use this?" Most "must have" historical data is accessed once or twice a year—not worth the migration effort. Keep legacy system accessible for occasional lookups.

Migration Timeline Planning

Data migration is not a single event—it's a process with multiple iterations.

Weeks 1-2: Assessment & Mapping
Inventory source data, assess quality, create field mappings
Weeks 3-4: Template Development
Build CSV templates, develop extraction queries, document transformations
Weeks 5-6: Test Migration #1
First full migration to sandbox, identify issues, refine process
Weeks 7-8: Test Migration #2
Second migration with fixes, validate data, train users on validation
Week 9: Test Migration #3 (Dress Rehearsal)
Full dress rehearsal with timing, sign-off from business
Week 10: Production Cutover
Final extraction, production load, validation, go-live
⚠️ The 3x Rule

Plan for at least three full test migrations before production. Each iteration reveals issues you couldn't anticipate. The third migration is your "dress rehearsal"—it should be identical to production and timed to verify your cutover window is realistic.

Chapter 11.2

Data Assessment

You can't migrate what you don't understand. Data assessment reveals the true state of your source data—the good, the bad, and the ugly.

Data Inventory

Start by cataloging every data source and understanding what's in each.

Source System Inventory

  • Primary ERP/Accounting: What's the main system of record?
  • Satellite Systems: CRM, e-commerce, WMS, HR systems
  • Spreadsheets: The shadow systems that fill gaps
  • Paper Records: Information not yet digitized

Data Volume Assessment

For each data type, document:

  • Total record count
  • Active vs. inactive records
  • Date range of historical data
  • Growth rate (for planning future capacity)

Transaction Count Scoping

Transaction volume is the primary driver of migration complexity and cost. Count your transactions before detailed planning begins.

Question Why It Matters
How many years of history? Beyond 2 years, cost-benefit diminishes rapidly
All transactions or sales only? Full GL rebuild vs. customer history focus
Posting transactions only? Exclude non-posting (quotes, estimates) from counts
💡 How to Count Transactions

From most legacy systems: Run a transaction detail report filtered by date range and transaction type. Export to Excel and count unique transaction numbers (not lines). A 10,000-line report may only be 2,000 unique transactions.

Key reports: Transaction List by Date, Transaction Detail by Account, or GL Detail. Filter to posting transactions only.

Data Quality Assessment

Assess the quality of source data across multiple dimensions.

Quality Dimensions

  • Completeness: Are required fields populated? What's the percentage of nulls?
  • Accuracy: Is the data correct? When was it last validated?
  • Consistency: Is the same data represented the same way everywhere?
  • Uniqueness: Are there duplicate records?
  • Timeliness: Is the data current? What's the update frequency?
  • Validity: Does data conform to expected formats and ranges?

Common Quality Issues by Data Type

Data Type Common Issues Impact if Not Fixed
Customers Duplicates, missing emails, inconsistent addresses, inactive marked as active Duplicate invoices, failed communications, inaccurate AR aging
Vendors Missing tax IDs, outdated payment info, duplicates 1099 issues, failed payments, inaccurate AP
Items Inconsistent naming, missing costs, wrong units of measure Inventory errors, margin miscalculation, order errors
Chart of Accounts Unmapped accounts, inconsistent hierarchy, obsolete accounts Failed imports, incorrect financial statements
Transactions Missing references, orphaned records, incorrect amounts Broken links, reconciliation issues, audit problems

Field Mapping

Create detailed mappings from source fields to NetSuite fields.

Mapping Document Structure

For each data type, document:

  • Source Field: Name and location in source system
  • Source Data Type: String, number, date, etc.
  • NetSuite Field: Target field in NetSuite
  • NetSuite Field Type: Text, list, date, etc.
  • Transformation: Any conversion or formatting required
  • Default Value: What to use if source is blank
  • Notes: Special considerations

Example: Customer Mapping

Source Field NetSuite Field Transformation Notes
CUST_ID externalId Prefix with "LEGACY-" Required for updates
COMPANY_NAME companyName Trim whitespace Required field
CUST_TYPE category Map: "R"→Retail, "W"→Wholesale Create list values first
CREDIT_LIMIT creditLimit None Numeric, no formatting
TERMS_CODE terms Map to NetSuite term names Create terms first
(none) subsidiary Default: "Parent Company" Required for OneWorld
💡 External ID Strategy

Always populate External ID with the legacy system's primary key. This allows you to update records after initial import and maintains traceability. Use a prefix like "LEGACY-" or "QBO-" to identify the source system.

Chapter 11.3

Data Cleansing

Clean data in the source system before migration, not after. It's always easier to fix problems at the source than to clean up after import.

Cleansing Principles

1. Clean at Source When Possible

Fix data in the legacy system before extraction. This ensures:

  • Users can validate fixes in familiar environment
  • Legacy reports remain accurate until cutover
  • Parallel processing is consistent across systems

2. Document Every Transformation

Track every change made to data:

  • What was changed
  • Why it was changed
  • Who approved the change
  • Original value (for audit trail)

3. Get Business Sign-Off

Data cleansing decisions are business decisions. The migration team proposes; business stakeholders approve.

Common Cleansing Tasks

Duplicate Resolution

Duplicates are the most common data quality issue.

  • Identify: Use matching rules (name, email, phone, address)
  • Analyze: Determine which record is the "master"
  • Merge: Combine transaction history onto master record
  • Inactivate: Mark duplicate records inactive
⚠️ Merge Before Migration

Merge duplicates in the legacy system before extraction. If you migrate duplicates and merge them in NetSuite, you'll have broken references to the deleted records in any integrations or external systems.

Standardization

Make data consistent across records:

  • Names: "IBM" vs "I.B.M." vs "International Business Machines"
  • Addresses: "Street" vs "St." vs "St"
  • Phone numbers: (555) 123-4567 vs 555-123-4567 vs 5551234567
  • States: "California" vs "CA" vs "Calif."

Enrichment

Fill in missing data:

  • Use business rules to derive missing values
  • Source from external data providers (D&B, ZoomInfo)
  • Default to placeholder values where appropriate

Validation

Verify data meets requirements:

  • Email addresses are valid format
  • Phone numbers are valid format
  • Postal codes match state/country
  • Tax IDs are valid format
  • Required fields are populated

Cleansing by Data Type

Customer Cleansing Checklist

Customer Data Cleansing

Item Cleansing Checklist

Item Data Cleansing

Data Cleansing Sign-Off

Before proceeding to migration, obtain formal sign-off that data is clean.

ℹ️ Sign-Off Includes

Business Owner Confirmation: "I have reviewed the cleansed data and confirm it is accurate and complete for migration to NetSuite."

Scope Confirmation: "I understand that only the data documented in the migration scope will be migrated. Historical data not in scope will remain in the legacy system."

Chapter 11.4

Migration Sequencing

Data must be migrated in a specific order due to dependencies. Load a sales order before its customer exists, and the import fails.

The Golden Rule of Sequencing

Always migrate data in this order:

  1. Lists (reference data that other records point to)
  2. Master Data (entities and items)
  3. Opening Balances (GL, inventory, AR/AP)
  4. Open Transactions (orders not yet fulfilled/billed)
  5. Historical Transactions (if migrating detail)
Migration Sequence
1
Lists & Setup
Currencies, subsidiaries, departments, classes, locations, payment terms, tax codes, price levels, custom lists
2
Chart of Accounts
Parent accounts first, then sub-accounts in hierarchy order
3
Vendors
Required before items (for preferred vendor) and purchase transactions
4
Items
Non-inventory items first, then inventory items, then assemblies/kits
5
Customers
Parent customers first, then child customers
6
Employees
If needed for transaction assignments or approvals
7
Opening Balances
GL journal entry, inventory adjustment, open AR/AP
8
Open Transactions
Open sales orders, open purchase orders, pending fulfillments

Chart of Accounts Migration Deep Dive

COA migration seems simple but has several gotchas. Here's the detailed process.

Step 1: Extract & Map Account Types

Account types don't translate one-to-one—legacy systems use generic types that need proper NetSuite classification.

QuickBooks Type NetSuite Type Notes
BankBankDirect match
Accounts ReceivableAccounts ReceivableDirect match
Other Current AssetOther Current Asset or Prepaid ExpenseReview each—prepaid rent/insurance should be Prepaid Expense
Fixed AssetFixed AssetDirect match
Accounts PayableAccounts PayableDirect match
Other Current LiabilityOther Current Liability or Deferred RevenueReview for customer deposits, unearned revenue
EquityEquityWatch for Retained Earnings (system-generated)
IncomeIncomeDirect match
Cost of Goods SoldCost of Goods SoldDirect match
ExpenseExpenseDirect match

Step 2: Handle System-Generated Accounts

NetSuite auto-creates certain accounts when features are enabled. Do not import duplicates—instead, rename the existing system accounts to match your legacy numbering.

System Account Created When Action
Accounts ReceivableA/R feature enabledRename existing, don't import
Accounts PayableA/P feature enabledRename existing, don't import
Retained EarningsAlways existsRename existing, don't import
Undeposited FundsPayments featureRename existing, don't import
Inventory AssetInventory feature enabledRename existing, don't import
🚨 Account Type Cannot Be Changed

Once an account is created, you cannot change its Account Type. If you import an account with the wrong type, you must delete it (if unused) or create a new account and remap. Get the type mapping right the first time.

💡 Account Import Tip

Import accounts in a single file sorted by account number. NetSuite will create parent-child relationships automatically if parent accounts are listed before their children. Disable multi-threading in Import Assistant—order matters for hierarchy.

Handling Circular Dependencies

Sometimes data has circular references that seem impossible to sequence.

Example: Item/Vendor Circular Dependency

Items can have a preferred vendor, and vendors can have a default expense account that's an item. Solution:

  1. Import vendors without default expense items
  2. Import items with preferred vendors
  3. Update vendors with default expense items

Example: Employee/Supervisor Dependency

Employees have supervisors who are also employees. Solution:

  1. Import all employees without supervisor references
  2. Update employees to add supervisor references
🎯 Consultant Insight

When you hit a circular dependency, the pattern is always the same: import records without the circular reference, then update them in a second pass. NetSuite's CSV import supports both "Add" and "Update" operations—use both.

Batch Loading Strategy

Don't try to load everything at once. Split your migration into deliberate batches aligned with project phases.

Batch When What Why
Batch 1 4-6 weeks before go-live Lists, COA, Vendors, Items, Customers Enables UAT and training with real data
Batch 2 2-3 weeks before go-live Historical trial balances, closed-period transactions Validates historical data without cutover pressure
Batch 3 Cutover: Thursday/Friday New master records created since Batch 1 Catches recent customers, vendors, items
Batch 4 Cutover: Saturday/Sunday Open AR/AP, open orders, final GL balance Requires operations to stop in legacy
💡 Why Batch Loading Matters

Loading closed-period data early lets users validate reports and practice workflows with real data—without the stress of cutover weekend. If you find issues, you have weeks to fix them, not hours.

Chapter 11.5

CSV Templates & Import

NetSuite's CSV import is the primary tool for data migration. Master the templates and import process to ensure clean, efficient data loads.

Obtaining Templates

Always start with NetSuite's official templates:

Setup → Import/Export → Import CSV Records
  1. Select the record type (Customer, Item, etc.)
  2. Click Download Template
  3. Choose fields to include in template
💡 Template Best Practice

Download a template that includes ALL fields you might need, even optional ones. It's easier to delete unused columns than to add them later. Include External ID in every template—you'll need it for updates.

CSV Formatting Rules

NetSuite is particular about CSV formatting. Follow these rules to avoid import errors.

General Rules

  • Encoding: UTF-8 (for international characters)
  • Delimiter: Comma (standard CSV)
  • Text qualifier: Double quotes for fields containing commas
  • Line endings: Windows (CRLF) or Unix (LF)
  • Header row: Required; must match NetSuite field names exactly

Field-Specific Rules

Field Type Format Example
TextPlain text, quote if contains comma"Acme, Inc."
NumberNo formatting, no currency symbols1234.56
DateM/D/YYYY or user's date preference12/31/2025
CheckboxT or F (or True/False)T
List/RecordInternal ID or Name/External IDNet 30 or 4
Multi-selectPipe-separated valuesValue1|Value2|Value3
EmailValid email formatjohn@example.com

Sublist Formatting

Records with sublists (like addresses, line items) require special formatting:

  • Each sublist row is a separate CSV row
  • Main record fields are on first row only
  • Sublist fields repeat on subsequent rows
External ID,Company Name,Address Label,Address Line 1,City,State,Zip CUST-001,Acme Corp,Main Office,123 Main St,New York,NY,10001 ,,Warehouse,456 Industrial Blvd,Newark,NJ,07102 CUST-002,Beta Inc,Headquarters,789 Corporate Dr,Chicago,IL,60601

Import Process

Step 1: Prepare the Import

Setup → Import/Export → Import CSV Records
  1. Select Import Type (Add, Update, or Add/Update)
  2. Select Record Type
  3. Upload your CSV file

Step 2: Field Mapping

  1. Review auto-mapped fields
  2. Manually map any unmatched fields
  3. Set default values for unmapped required fields
  4. Configure list matching (by name or internal ID)

Step 3: Preview & Run

  1. Preview first 10 records
  2. Review for obvious errors
  3. Save mapping for reuse
  4. Run import (or schedule for later)
⚠️ Save Your Mappings

Always save import mappings after configuration. You'll run the same import multiple times during test migrations. Saved mappings prevent re-doing field mapping every time.

Pro Tips for Reliable Imports

Use Internal IDs, Not Names

Whenever possible, reference records by internal ID instead of name. Names can have duplicates, special characters, or change over time.

Disable Auto-Numbering for Historical Data

To preserve legacy document numbers (invoice numbers, PO numbers, etc.):

Setup → Company → Auto-Generated Numbers
  1. Enable Allow Override for the relevant transaction type
  2. Import with your legacy document numbers
  3. After migration, set the starting number higher than your highest imported number

Prevent Accidental Notifications

When importing transactions, set these fields to prevent unwanted emails/faxes:

  • To Be Emailed: F
  • To Be Faxed: F
  • To Be Printed: F
🚨 Test Single Record First

Before bulk importing 10,000 records, import exactly ONE. Verify every field mapped correctly, check GL impact, confirm workflows don't trigger unintended actions. Then proceed with the full load.

Common Import Errors

Error Cause Solution
"Invalid reference" Referenced record doesn't exist Check that referenced record was imported first; verify spelling
"You must enter a value for..." Required field is blank Populate field or set default in mapping
"Duplicate record" Record with same key already exists Use Update instead of Add, or remove duplicate
"Invalid date format" Date doesn't match expected format Use M/D/YYYY format; check user preferences
"Invalid number" Number has formatting characters Remove currency symbols, commas, etc.
"Permission error" User can't create this record type Run import as Administrator or adjust permissions
Chapter 11.6

Test Migrations

Test migrations reveal problems before production. Each iteration should be faster and cleaner than the last, building confidence for cutover.

Test Migration Objectives

Each test migration serves specific purposes:

Test Migration #1: Process Validation

  • Validate extraction queries work
  • Confirm field mappings are correct
  • Identify data quality issues
  • Test import sequencing
  • Establish baseline timing

Test Migration #2: Data Validation

  • Apply cleansing fixes from TM1
  • Verify data accuracy with business users
  • Test transactions and balances
  • Refine timing estimates

Test Migration #3: Dress Rehearsal

  • Execute exactly as production
  • Follow cutover checklist step by step
  • Time every activity
  • Full business validation
  • Go/no-go decision input

Sandbox Refresh Strategy

Test migrations require a clean sandbox environment.

Before Each Test Migration

  1. Request sandbox refresh from production (if needed)
  2. Or delete test data from previous migration
  3. Verify configuration is current
  4. Confirm all users can access sandbox
ℹ️ Sandbox Refresh Timing

Sandbox refreshes take 4-24 hours depending on account size. Plan ahead—don't assume you can refresh and test same-day. Also note that refreshes overwrite everything, including configuration you may have done.

Validation Procedures

Define specific validation checks for each data type.

Record Count Validation

Compare counts between source and NetSuite:

Data Type Source Count NetSuite Count Variance Status
Active Customers4,2004,2000✓ Pass
Active Vendors850848-2⚠ Review
Active Items12,00012,0000✓ Pass

Financial Validation

  • Trial Balance: Does NetSuite TB match legacy TB as of cutover date?
  • AR Aging: Does open AR total match? Do aging buckets match?
  • AP Aging: Does open AP total match? Do aging buckets match?
  • Inventory Value: Does inventory value match legacy?

Spot-Check Validation

Have business users verify a sample of records:

  • Top 10 customers by revenue—all fields correct?
  • Top 10 vendors by spend—all fields correct?
  • Top 20 items by sales—costs and prices correct?
  • 10 random open orders—all lines and amounts correct?

Test Migration Documentation

Document each test migration thoroughly.

Test Migration Report Contents

Cleaning Up Between Test Migrations

After each test migration, you may need to delete records to reset for the next iteration.

Method 1: Manual Deletion (< 5 records)

For a handful of records, delete manually via Actions → Delete.

Method 2: Mass Delete (5-500 records)

Lists → Mass Delete

Select record type, apply filters, preview and confirm deletion.

Method 3: Saved Search + Bulk Delete Script (500+ records)

For large-scale cleanup, use a Map/Reduce script that deletes based on saved search criteria.

💡 Deactivate vs. Delete

For master data (customers, vendors, items), consider deactivating instead of deleting. Deactivation is reversible and preserves audit trails. Reserve deletion for true cleanup of test data.

Chapter 11.7

Inventory & Trial Balance

Opening balances are the most critical—and most error-prone—part of migration. Get the trial balance and inventory wrong, and financial statements are wrong from day one.

Opening Balance Strategy

There are two approaches to opening balances, each with tradeoffs.

⚖️ Key Decision

Opening Balance Approach

🎯 Consultant Recommendation

For most implementations, summary balances are the right choice. The effort to migrate historical transaction detail is rarely worth it. Keep the legacy system accessible for historical research. Focus your energy on getting opening balances accurate.

Trial Balance Migration

The opening trial balance is typically loaded as a single journal entry.

Process

  1. Run trial balance in legacy system as of cutover date
  2. Map legacy accounts to NetSuite accounts
  3. Create journal entry in NetSuite with one line per account
  4. Verify debits equal credits
  5. Post journal entry dated as of cutover date

Special Handling

  • AR/AP: Don't include in TB journal entry—load via open invoices/bills
  • Inventory: Don't include in TB journal entry—load via inventory adjustment
  • Intercompany: Ensure IC balances net to zero across subsidiaries
  • Retained Earnings: May need adjustment to balance
🚨 Critical: AR/AP and Inventory

Never load AR, AP, or Inventory via the opening journal entry. These accounts are controlled by their respective transactions (invoices, bills, inventory adjustments). Loading them via JE creates a mismatch between sub-ledger and GL that's extremely difficult to reconcile.

Accounts Receivable Opening Balance

Open AR is loaded by importing the individual open invoices.

Process

  1. Extract open (unpaid) invoices from legacy system
  2. Include invoice date, due date, amount, customer
  3. Import as invoices in NetSuite
  4. Verify AR aging report matches legacy

Considerations

  • Partial payments: Import net amount due, not original invoice amount
  • Credits: Import open credits as credit memos
  • Aging accuracy: Invoice date drives aging—don't use cutover date for all
💡 AR Simplification Option

If you don't need detailed invoice history, import a single "Opening Balance Invoice" per customer with total amount due. This is faster but loses invoice-level detail for customer statements and collections.

Inventory Opening Balance

Inventory is loaded via inventory adjustment, not journal entry.

Process

  1. Perform physical inventory count as close to cutover as possible
  2. Reconcile count to legacy system
  3. Export item quantities and costs by location
  4. Import as inventory adjustment in NetSuite
  5. Verify inventory valuation report matches legacy

Costing Considerations

  • Average cost: Import quantity and total value; system calculates average
  • Standard cost: Set standard costs on items before adjustment
  • FIFO: May need to import multiple cost layers
  • Lot/Serial: Import with lot/serial numbers for traceability
⚠️ Inventory Timing

Inventory counts should be done as close to cutover as possible. Any transactions between count date and cutover must be manually adjusted. Ideally, freeze inventory movement during cutover weekend.

Balance Validation Checklist

Opening Balance Validation

Chapter 11.8

Cutover Planning

Cutover is the culmination of months of work compressed into a single weekend. Meticulous planning is the difference between a smooth transition and chaos.

Hard vs. Soft Cutover

Before planning your cutover weekend, decide which cutover strategy fits your situation.

Approach Description Pros Cons
Hard Cutover Complete switch on a specific date. Legacy system stops, NetSuite starts. Clean break; no dual-system management; faster transition Higher pressure weekend; audit may span both systems for the year
Soft Cutover Run parallel through year-end. Migrate after legacy fiscal year closes. All historical data in one system; aligned with fiscal year; less pressure Dual data entry; delayed go-live; complex reconciliation
🎯 When to Choose Each

Hard cutover works best when migrating detailed transactions—the soft approach's benefits disappear if you're loading historical invoices anyway. Soft cutover suits summary-only migrations where you want a clean fiscal year boundary and can afford to wait.

⚠️ Avoid January 1st

Don't schedule cutover for January 1st or the first week of January. Your accounting team is busy with year-end close. Holiday vacations thin the team. Aim for late January or early February if crossing fiscal years.

Third-Party Notifications

Before cutover, notify all parties affected by the system change.

Party Why When
External AuditorsThey'll need to audit across two systems; may want to observe cutover2-3 months before
BanksPayment file formats may change; positive pay setup needed1 month before
AP Automation (Bill.com, etc.)Integration reconfiguration; avoid duplicate vendor/bill creation2-4 weeks before
Payment ProcessorsNew integration credentials; test transactions needed2-4 weeks before
EDI/Integration PartnersNew endpoints; format changes; testing required4-6 weeks before
Tax Services (Avalara, etc.)New company/account setup; address validation testing2-4 weeks before
Payroll ProviderGL account mapping; integration setup4-6 weeks before
🚨 AP Automation Warning

If you use Bill.com or similar AP automation, coordinate carefully. These systems sync vendors and bills bidirectionally. A poorly-timed sync after cutover can create duplicate vendors or import bills that were already migrated.

Cutover Window

Most cutover happens over a weekend to minimize business disruption.

Typical Cutover Timeline

Friday 5:00 PM
Legacy system frozen—no new transactions
Friday 6:00 PM
Final data extractions begin
Friday 10:00 PM
Data transformations complete
Saturday 8:00 AM
Production data load begins
Saturday 6:00 PM
Data load complete; validation begins
Sunday 12:00 PM
Validation complete; Go/No-Go decision
Sunday 4:00 PM
Final configuration and user access
Monday 8:00 AM
Go-Live: Users begin working in NetSuite

Go/No-Go Criteria

Define specific, measurable criteria for the go-live decision.

Must Pass (Blockers)

  • Trial balance matches legacy within $100
  • AR aging total matches within $500
  • AP aging total matches within $500
  • Inventory value matches within 1%
  • All critical users have working access
  • Integration connections verified
  • No severity-1 issues open

Should Pass (Acceptable with workaround)

  • All test transactions complete successfully
  • Reports generate expected results
  • Workflows trigger correctly
🚨 No-Go Decision Authority

Designate a single person with authority to make the No-Go decision. This should be an executive sponsor, not the project manager. The PM presents the facts; the sponsor decides. A No-Go is not failure—it's risk management.

Rollback Plan

If cutover fails, you need a plan to return to the legacy system.

Rollback Triggers

  • Go/No-Go criteria cannot be met
  • Data corruption discovered
  • Critical functionality not working
  • Executive decision to abort

Rollback Process

  1. Re-enable legacy system write access
  2. Communicate rollback to all users
  3. Document what happened and why
  4. Schedule post-mortem analysis
  5. Plan revised cutover date
⚠️ Rollback Window

Once users start entering transactions in NetSuite, rollback becomes extremely difficult. Set a "point of no return"—typically Sunday noon. After that point, you're committed to making NetSuite work.

Chapter 11.9

Historical Transaction Migration

When summary balances aren't enough, you need a strategy for migrating detailed transaction history. This chapter covers when historical detail is required, the technical approaches, and the trade-offs involved.

When Historical Detail Is Required

Most implementations should migrate summary balances only. However, certain business requirements demand detailed transaction history:

Legitimate Requirements for Historical Detail

  • Audit Requirements: External auditors require transaction-level detail for the current audit period (typically current year + prior year)
  • Warranty/Service History: Customer service needs to see past orders, returns, and service history for warranty claims
  • Project Accounting: Long-running projects with costs spanning multiple years require full job cost history
  • Revenue Recognition: ASC 606 compliance may require original contract details for deferred revenue schedules
  • Regulatory Compliance: Industry-specific retention requirements (healthcare, financial services)
  • Commission History: Sales commission disputes require original transaction records
⚖️ Key Decision

Historical Detail Decision Matrix

GL Rebuilding Approaches

When migrating historical transactions, you're essentially rebuilding the General Ledger in NetSuite.

Approach 1: Period-by-Period Journal Entries

Create summary journal entries for each closed period, one per month or quarter.

Pros Cons
Clean, auditable trailNo transaction detail
Fast to implementCannot drill down to source documents
Easy to validate (TB must match)Loses subsidiary ledger detail
Works for any legacy systemCustomer/vendor statements won't show history

Approach 2: Transaction-Level Import

Import individual invoices, bills, payments, and other transactions with original dates.

⚠️ Transaction Import Complexity

Transaction-level import is 10x more complex than summary journals. You must handle: posting dates vs. transaction dates, payment applications, voided transactions, adjustments, discounts, and tax calculations. Only attempt this if the business case is strong.

Approach 3: Hybrid (Recommended for Most)

Combine summary journals for old history with transaction detail for recent periods. Set the hybrid boundary at your last closed fiscal year. Summary journals for all prior closed years, transaction detail for current year and current open items.

💡 Hybrid Boundary Recommendation

This balances audit requirements with migration complexity.

Posting Date Decisions

When importing historical transactions, you must decide how to handle dates.

🚨 Date vs. Posting Period: Critical Distinction

NetSuite has two date concepts that behave differently:

  • Date Field: The transaction date shown on documents. Used for aging reports (AR/AP aging uses this date).
  • Posting Period: The accounting period for GL impact. Financial statements use this period.

The problem: If you import open AR with original transaction dates (for aging) but post the GL impact to a cutover period, the AR aging report will show invoices as 90+ days old, but the trial balance will show all AR in the current period. This is expected behavior, but it confuses users who don't understand the distinction.

Option A: Original Transaction Dates

  • Transactions post to their original periods
  • Historical reports match legacy system
  • Requires opening all historical periods during migration
  • Risk: Users or processes may accidentally post to old periods

Option B: Conversion Date

  • All historical transactions post to a single "conversion" period
  • Original date stored in a custom field or memo
  • Simpler period management
  • Trade-off: Historical period reports show zero; must filter by custom date field

Option C: Period-End Posting

  • Transactions post to the last day of their original period
  • Preserves period totals without exact daily detail
  • Good compromise for reporting needs
🎯 Consultant Recommendation

Use Option A (original dates) only if you have strong controls during migration. Lock all periods immediately after load. For most projects, Option C (period-end posting) provides the best balance of historical accuracy and operational safety.

Custom Fields for Historical Data

Establish consistent conventions for identifying migrated historical data.

Field Type Purpose
Legacy Document NumberFree-Form TextOriginal reference for cross-system lookups
Legacy Transaction DateDateOriginal date if posting date differs
Migration Batch IDFree-Form TextLinks to migration log for troubleshooting
Is MigratedCheckboxFilter migrated vs. native transactions
Legacy Source SystemListFor migrations from multiple legacy systems
ℹ️ Search and Reporting

Create a saved search for "All Migrated Transactions" using the Is Migrated checkbox. This allows quick filtering when troubleshooting post-migration issues or reconciling to legacy.

Chapter 11.10

Multi-Subsidiary Migration

OneWorld implementations add significant complexity to data migration. Each subsidiary has its own chart of accounts, currencies, and potentially different legacy systems. This chapter provides the framework for coordinating multi-subsidiary migrations.

Multi-Subsidiary Migration Challenges

OneWorld migrations compound every data migration challenge:

  • Multiple Source Systems: Each subsidiary may have its own legacy ERP
  • Currency Complexity: Each subsidiary has a base currency; transactions may be in foreign currencies
  • Shared vs. Non-Shared Records: Some entities span subsidiaries; others are subsidiary-specific
  • Intercompany Balances: IC receivables/payables must net to zero
  • Consolidation Requirements: Post-migration, consolidated financials must match pre-migration
  • Timing Coordination: All subsidiaries typically go live together
🚨 Big Bang vs. Phased

Most OneWorld implementations require "big bang" migration—all subsidiaries go live simultaneously. Phased subsidiary rollouts create intercompany complexity that most organizations cannot manage. Plan for all subsidiaries in the same cutover window.

Subsidiary Load Sequence

The order in which you load subsidiaries and their data matters.

Recommended Sequence
1
Parent Subsidiary
Setup & COA
2
Child Subsidiaries
Setup & COA
3
Shared Master Data
Items, Vendors, Customers
4
Subsidiary-Specific
Master Data
5
Opening Balances
Per Subsidiary
6
Intercompany Balances
7
Open Transactions
Per Subsidiary
8
Consolidation Validation

Shared vs. Subsidiary-Specific Records

NetSuite OneWorld allows records to be shared across subsidiaries or restricted to specific ones.

Shared Records (Global)

These records are available to all subsidiaries:

  • Items (inventory, service, non-inventory) — most commonly shared
  • Customers who transact with multiple subsidiaries
  • Vendors who supply multiple subsidiaries
  • Employees (if shared services model)
  • Classes, Departments, Locations (can be shared or subsidiary-specific)

Subsidiary-Specific Records

These records belong to a single subsidiary:

  • Customers who only transact with one subsidiary
  • Vendors specific to one location/country
  • Employees (typically subsidiary-specific)
  • Bank accounts
  • All transactions
💡 Shared Record Strategy

Default to shared items unless there's a reason to restrict. For customers and vendors, analyze transaction history: if they've transacted with multiple subsidiaries in the past, make them shared. This simplifies ongoing maintenance and reporting.

Intercompany Opening Balances

Intercompany balances are often the trickiest part of OneWorld migration.

The IC Balance Challenge

At any point in time, intercompany receivables must equal intercompany payables across all subsidiaries. If Sub A owes Sub B $100,000, Sub A has an IC Payable and Sub B has an IC Receivable—these must match exactly.

IC Balance Migration Process

  1. Extract: Pull IC balances from each legacy system as of cutover date
  2. Reconcile: Match IC receivables to IC payables across subsidiaries
  3. Resolve Differences: Investigate and clear any discrepancies before migration
  4. Load: Use intercompany journal entries or opening balance journals
  5. Validate: Run IC Balances report; must net to zero
⚠️ Currency on IC Balances

Intercompany balances may be denominated in different currencies in each subsidiary's books. Ensure you're using consistent exchange rates. Best practice: convert all IC balances to a common currency for reconciliation, then load in each subsidiary's base currency.

Consolidation Validation

After migrating all subsidiaries, validate that consolidated financials are correct.

Consolidation Validation

Setup → Accounting → Manage G/L → Financial Statements → Consolidated Balance Sheet
🎯 Consultant Recommendation

Run consolidated financials in both legacy and NetSuite as of the same date. Differences should only be rounding or known timing differences. If consolidated net income differs by more than $1,000, investigate before go-live.

Chapter 11.11

Open Transactions Deep Dive

Open transactions—orders not yet fulfilled, invoices not yet paid, POs not yet received—require careful handling to ensure business continuity from day one.

Types of Open Transactions

Open transactions fall into several categories, each with unique migration requirements:

Order-to-Cash

  • Open Sales Orders
  • Partially Fulfilled SOs
  • Open Invoices (Unpaid AR)
  • Unapplied Customer Payments & Credits

Procure-to-Pay

  • Open Purchase Orders
  • Partially Received POs
  • Open Vendor Bills (Unpaid AP)
  • Unapplied Vendor Payments & Credits

Other

  • Customer Deposits
  • Prepaid Expenses
  • Deferred Revenue

Open Sales Orders

Open sales orders are customer commitments that must be fulfilled after go-live.

Partially Fulfilled Orders

Orders where some lines have shipped require more complex handling:

Approach Pros Cons Best For
Remaining Quantity Only Simple import; clean order Loses partial fulfillment history Most implementations
Full Order + Fulfillments Complete history in NetSuite Complex; must load fulfillments and invoices When order history is critical

Orders with Deposits

Customer deposits applied to open orders require special handling:

  1. Import the sales order first
  2. Import the customer deposit linked to the sales order
  3. Verify deposit appears on sales order record
  4. On fulfillment/invoice, deposit auto-applies
⚠️ Deposit Timing

Customer deposits must be imported AFTER the sales order exists. The deposit record references the sales order. If you're importing both, ensure sales orders load first.

Unapplied Customer Payments

Customers may have credit balances from overpayments or unapplied payments.

Types of Customer Credit Balances

  • Unapplied Payments: Payment received but not applied to an invoice
  • Credit Memos: Credits issued for returns or adjustments
  • Overpayments: Customer paid more than invoice amount
  • Deposits on Account: Advance payments not tied to specific order
💡 Clean Up Before Migration

Unapplied payments are often data quality issues that have accumulated over years. Before migration, review all unapplied amounts with AR. Many can be applied, written off, or refunded—reducing migration complexity.

Deferred Revenue

Deferred revenue from subscriptions, service contracts, or advance billings requires careful migration.

Approach Description Best For
Summary Balance Only Load total deferred revenue in opening JE; manually track recognition Low volume, simple recognition
Contract-Level Import Import each contract with remaining recognition schedule ASC 606 compliance, audit requirements
Use Advanced Revenue Management Import contracts into ARM module with schedules Complex rev rec, multiple elements
🚨 Revenue Recognition Compliance

For publicly traded companies or those with ASC 606 requirements, deferred revenue migration is an audit-sensitive area. Work with your auditors to agree on the migration approach before implementation. Document the bridge from legacy deferred revenue to NetSuite opening balance.

Open Transaction Validation

Open Transaction Validation

🎯 Consultant Insight

The most common post-go-live issue is "I can't fulfill this order" or "the deposit didn't apply." Test at least 5 open orders end-to-end before cutover. Include orders with deposits, partial fulfillments, and multiple lines.

Industry-Specific Considerations

🏭 Manufacturing
Manufacturing

Work Orders: Open work orders in production must be migrated or closed and re-created. Consider WIP (Work in Process) accounting implications—costs already incurred on incomplete WOs must be captured.

💻 Software/SaaS
Software/SaaS

Subscription Contracts: Each active subscription with remaining term creates deferred revenue. If using Advanced Revenue Management, import contract details with revenue recognition schedules.

👔 Professional Services
Professional Services

Projects in Progress: Open projects with unbilled time/expenses require WIP journal entries. If using Project Billing, migrate project records with unbilled amounts.

📦 Wholesale/Distribution
Wholesale/Distribution

Blanket POs: Standing purchase agreements should be migrated as blanket POs with remaining commitment amounts. Link future purchase orders to blanket for tracking.

🛒 Retail
Retail

Gift Cards: Outstanding gift card liability must be migrated. Each unredeemed gift card can be imported as a credit memo or tracked in a gift card register depending on volume.

💚 Nonprofit
Nonprofit

Pledges Receivable: Multi-year pledges with scheduled payments should be imported as customer records with open invoices or as pledge transactions if using nonprofit features.

Chapter 11.12

Migration Pro Tips

Expert insights and battle-tested techniques from data migration specialists to help you avoid common pitfalls and ensure a smooth go-live.

ℹ️ Source Attribution

The tips in this chapter are contributed by Paul Giese, NetSuite data migration expert and founder of OptimalData Consulting.

1. Troubleshooting Missing Fields in CSV Imports

If you've opened the CSV Import tool and wondered why certain fields aren't available to map, the issue is often the form selection. The form you select in Step 2 of the import controls the entire field list on the mapping screen—and this setting is frequently hidden in the "Advanced Options" section.

💡 The Fix
  1. Go to Setup → Import/Export → Import CSV Records
  2. Select your Import Type and Record Type
  3. Before uploading the file, expand Advanced Options
  4. Update the Custom Form dropdown to the form you want to work with
  5. Continue to Step 3—you'll see a completely different list of available fields

This is especially important when importing entities with custom forms (e.g., different customer forms for B2B vs. B2C) or transactions with industry-specific fields.

2. The Importance of Detailed Historical Transactions

Most companies go live on NetSuite with clean configurations but only summary balances for historical data. While this approach gets you live faster, it creates significant roadblocks for analytics and AI functionality.

⚠️ Why Summary-Only Migration Hurts You Later
  • AI cannot identify trends without multi-year transaction history
  • Vendor-level analytics lack context without granular purchase data
  • Cash flow forecasting suffers without historical payment timing data
  • Customer behavior analysis requires order history, not just AR balances
  • Seasonal patterns are invisible without detailed transaction dates

If timeline permits, consider loading 2-3 years of detailed transactions. The incremental effort pays dividends when you want to leverage NetSuite Analytics Warehouse or AI-powered features.

🎯 Consultant Insight

If you can't load full transaction detail, prioritize: (1) detailed AR aging by invoice, (2) purchase history by vendor, and (3) sales by customer/item. These three datasets power 80% of the analytics questions executives ask.

3. Best Practices for Importing Open AR

Open AR is essential for a successful go-live. Customers need to see their correct balances, and collections must continue without interruption.

Step Action Why It Matters
1Align CurrenciesImport must match original invoice currency—not payment currency or reporting currency
2Validate BalancesCustomer balances must tie to legacy AR subledger before proceeding
3Use Clearing AccountImport invoices against a clearing account to avoid re-recognizing revenue
4Suspense-Clearing EntryFinal journal entry zeros the clearing account and ensures aging report accuracy

4. Bank Reconciliation on Day 1

Most teams using the net change method forget to load every open bank transaction as of go-live. This causes the bank reconciliation to fail on Day 1—a painful way to start.

💡 The Recommended Approach
  1. Identify all uncleared transactions from the legacy system (outstanding checks, deposits in transit)
  2. Load each open bank transaction through a suspense account
  3. Post a reversing journal entry to zero out the GL impact
  4. The transactions now appear in NetSuite's bank register, ready for reconciliation

This keeps the reconciliation clean and matches the legacy system immediately. Your first bank rec in NetSuite should reconcile with minimal effort.

5. Audit-Ready: The Detailed Trial Balance

Instead of building saved searches and exporting to spreadsheets for audits, customize the standard Trial Balance report to include the fields auditors always request:

Add This Field Label As Why Auditors Need It
Internal IDAccount IIDUnique identifier for account mapping
Account Type: Long NameAccount TypeDistinguishes between similar account names
Department → NameDepartmentCost center analysis
Class → NameClassBusiness line/product line breakdown
Location → NameLocationMulti-location compliance

Save this as a custom report. It becomes a repeatable, reliable artifact you can hand to auditors every period without manual spreadsheet work.

6. Identifying Uncleared Transactions

The "Cleared" indicator does not reliably surface in saved searches. This trips up many teams trying to build reconciliation reports. Two reliable alternatives:

Option A: Register View

  1. Go to Lists → Accounting → Chart of Accounts
  2. Click into the bank account
  3. Expose the "Cleared" column directly on the register
  4. Filter or sort to find uncleared items

Option B: Analytics Workbooks

SuiteAnalytics Workbooks expose fields that saved searches cannot access. Create a workbook with the Transaction dataset and add the clearing status field—this gives you a cleaner "what's still open" view that you can pivot and filter.

ℹ️ Why This Matters

Bank reconciliation issues are one of the top support tickets in the first month after go-live. Having a reliable way to identify uncleared transactions prevents hours of troubleshooting.

7. Strategy: The Controlled Cutover

The best go-lives are not "big bangs"—they are controlled, prioritized, and pragmatic. If timelines are tight, focus on what matters most:

1
12/31 Trial Balance

Clean, reconciled opening balances

2
Open AP

Essential for vendor payments

3
Open AR

Essential for collections

4
Integration Validation

Test during buffer window

⚠️ Critical Insight

You can always backfill historical data later, but you cannot easily recover trust once a go-live date slips. Prioritize operational continuity over data completeness when timelines are at risk.

8. Handling Complex Purchase Orders

When migrating open purchase orders—especially across subsidiaries—you may encounter lines where the remaining quantity to receive does not equal the remaining quantity to bill. This happens when:

  • Partial receipts occurred but billing is delayed
  • Goods were received but invoice not yet entered
  • Three-way matching is in different states per line
💡 Proposed Workaround
  1. Set the open PO quantity equal to the remaining quantity to be received (keeps it operationally meaningful)
  2. For pending billing amounts, enter the vendor bill without the PO assigned under the Related Records subtab
  3. Create a custom field on the Related Records subtab to link to the legacy PO transaction for audit trail

This approach preserves operational functionality (receiving against the PO) while capturing the billing liability separately. Document the methodology for auditors.