Phase 11 of 14

Data Migration

Data migration is where implementations succeed or fail. More projects go off track due to data issues than any other factor. This phase provides the framework for migrating data cleanly, completely, and on schedule.

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

🎯 Historical Data: Migrate or Archive?
Migrate to NetSuite
If: Data is actively referenced in daily operations, needed for real-time reporting, or must appear on live transactions (e.g., customer purchase history affects pricing).
Summary Only
If: Need historical balances for reporting but not transaction detail. Migrate as summary journal entries.
Data Warehouse
If: Historical data needed for analytics but not operational use. Move to separate reporting database.
Archive in Legacy
If: Data rarely accessed, only needed for occasional audit or legal research. Keep legacy system read-only.
💡 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)
Data Type Total Records Active To Migrate Source System
Customers 15,000 4,200 4,200 Legacy ERP
Vendors 3,500 850 850 Legacy ERP
Items 45,000 12,000 12,000 Legacy ERP + Spreadsheets
Open Sales Orders 1,200 1,200 1,200 Legacy ERP
Historical Invoices 250,000 N/A 0 (archive) Legacy ERP

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
Identify and merge duplicate customers
Verify all active customers have valid email addresses
Standardize address formats
Validate tax exemption certificates are current
Review and update credit limits
Mark inactive customers appropriately
Assign customers to correct subsidiary (OneWorld)

Item Cleansing Checklist

📋 Item Data Cleansing
Standardize item naming conventions
Verify all items have correct item type
Validate costs are populated and reasonable
Confirm units of measure are correct
Mark discontinued items as inactive
Assign items to correct subsidiary (OneWorld)
Verify income/expense/asset accounts are mapped

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

Detailed Sequencing by Data Type

1. Lists & Setup Data

These must exist before master data can reference them.

  1. Currencies (if multi-currency)
  2. Subsidiaries (if OneWorld)
  3. Locations
  4. Departments
  5. Classes
  6. Custom segments
  7. Payment terms
  8. Tax schedules and tax codes
  9. Price levels
  10. Customer categories
  11. Vendor categories
  12. Item categories
  13. Custom list values

2. Chart of Accounts

Account hierarchy matters:

  1. Top-level parent accounts (summary accounts)
  2. Second-level accounts
  3. Third-level accounts (and so on)
  4. Posting accounts at lowest level
✅ 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.

3. Items

Item dependencies require careful ordering:

  1. Service items and non-inventory items (no dependencies)
  2. Inventory items (depend on accounts, may depend on vendors)
  3. Assembly/BOM items (depend on component items)
  4. Kit items (depend on member items)
  5. Matrix parent items
  6. Matrix child items (depend on parent and option values)

4. Customers & Vendors

Parent-child relationships require ordering:

  1. Parent companies (no parent specified)
  2. Child companies (reference parent)
  3. Contacts (associated with companies)

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.

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:

  1. Navigate to Setup → Import/Export → Import CSV Records
  2. Select the record type (Customer, Item, etc.)
  3. Click Download Template
  4. 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
Text Plain text, quote if contains comma "Acme, Inc."
Number No formatting, no currency symbols 1234.56
Date M/D/YYYY or user's date preference 12/31/2025
Checkbox T or F (or True/False) T
List/Record Internal ID or Name/External ID Net 30 or 4
Multi-select Pipe-separated values Value1|Value2|Value3
Email Valid email format john@example.com
Phone Any format (NetSuite doesn't validate) (555) 123-4567

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

  1. Navigate to Setup → Import/Export → Import CSV Records
  2. Select Import Type (Add, Update, or Add/Update)
  3. Select Record Type
  4. 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)

Step 4: Review Results

  1. Check import job status
  2. Download error file if any failures
  3. Analyze and fix errors
  4. Re-import failed records
⚠️ 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.

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 Customers 4,200 4,200 0 ✓ Pass
Active Vendors 850 848 -2 ⚠ Review
Active Items 12,000 12,000 0 ✓ 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
Execution Timeline: Start/end times for each step
Record Counts: Source vs. imported vs. failed
Error Summary: Types of errors encountered
Validation Results: Pass/fail for each check
Issues Found: New issues discovered
Remediation Plan: How issues will be fixed
Lessons Learned: Process improvements for next iteration
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.

🎯 Opening Balance Approach
Summary Balances
Migrate only account balances as of cutover date. Simplest approach; no transaction history in NetSuite. Use legacy system for historical detail.
Detail Migration
Migrate individual transactions (invoices, bills, etc.). Provides history in NetSuite but significantly more complex and time-consuming.
💡 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.

Accounts Payable Opening Balance

Open AP is loaded by importing individual open vendor bills.

Process

  1. Extract open (unpaid) vendor bills from legacy system
  2. Include bill date, due date, amount, vendor
  3. Import as vendor bills in NetSuite
  4. Verify AP aging report matches legacy

Considerations

  • Partial payments: Import net amount due
  • Vendor credits: Import as vendor credits
  • Accrued expenses: May need separate journal entry

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
Trial balance totals match legacy system (debits = credits)
AR aging total matches legacy AR aging total
AR aging by bucket (current, 30, 60, 90+) matches legacy
AP aging total matches legacy AP aging total
AP aging by bucket matches legacy
Inventory valuation matches legacy
Inventory by location matches legacy
Bank account balances match bank statements
Fixed asset register matches legacy
CFO/Controller sign-off on opening balances
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.

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

Cutover Checklist

Create a detailed, task-level checklist with owners and timing.

Time Task Owner Duration Status
Fri 5:00 PM Announce system freeze to all users PM 15 min ☐
Fri 5:15 PM Disable legacy system write access IT 15 min ☐
Fri 5:30 PM Process final transactions in legacy Finance 1 hr ☐
Fri 6:30 PM Extract final customer data Tech 30 min ☐
Fri 7:00 PM Extract final vendor data Tech 30 min ☐
... detailed tasks continue ...

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.

Communication Plan

Keep stakeholders informed throughout cutover.

Communication Schedule

  • Friday 5:00 PM: "System freeze in effect"
  • Saturday 8:00 AM: "Migration started as planned"
  • Saturday 6:00 PM: "Migration complete, validation underway"
  • Sunday 12:00 PM: "Go/No-Go decision: GO" or "No-Go: [reason]"
  • Monday 7:00 AM: "NetSuite is live—welcome message and support info"

Support Plan for Day 1

  • War room with migration team on-site
  • Dedicated support channel (Slack, Teams, phone)
  • Super-users stationed in each department
  • Triage process for incoming issues
  • Executive availability for escalations

Post-Cutover Validation

Validation continues after go-live.

Day 1 Validation

  • Create a test sales order and invoice
  • Create a test purchase order and receipt
  • Process a test payment receipt
  • Process a test vendor payment
  • Verify integrations are processing

Week 1 Validation

  • First payroll processing (if applicable)
  • Bank reconciliation
  • First customer statements
  • First scheduled reports

Month-End Validation

  • Full month-end close process
  • Financial statement preparation
  • Comparison to legacy for same period
  • Audit of conversion balances