This article outlines the minimum viable setup for going live with Light and helps you prepare for a successful transition from your legacy financial system.
Last updated May 21, 2026 · 8 min read
Before starting, align your team on these terms:
Cutoff Date — The last day you operate in your legacy system (end of day). This is the reference point for your Trial Balance, open items, and releases. All transactions before this date stay in the legacy system for historical reference.
Go-Live Date — The first day you operate in Light. From this date forward, Light is your system of record. All new transactions are created and managed in Light.
Migration Suspense Account — A temporary balance sheet account used in Light to offset migrated AP and AR balances during the cutover import. After all cutover imports are complete, this account must net to zero.
Successful go-live requires careful planning and testing. This article helps you verify that Light is ready for production use and that your organization is prepared for the transition.
Your Light instance is ready for go-live when it includes:
User and permissions
Organization structure
Bank connectivity
Financial workflows
Integration connectivity
Additional setup
Cards (if applicable)
Master data
Before cutover, complete the following in your legacy system. These steps reduce migration issues more than anything else.
1. Reconcile subledgers to GL
If differences exist, correct them in the legacy system. Do not attempt to patch differences in Light.
2. Clean up open items
The goal is to migrate clean, consistent data.
3. Confirm prior year close Ensure the previous year-end close (e.g. 2024) is completed in the legacy system — especially important if importing only current-year journals.
4. Complete COA mapping Every account used in the agreed historical period must be mapped to a Light account code. Missing mappings are a common cause of migration delays.
5. Prepare accruals schedule Document all ongoing accruals to carry forward operationally:
If you're transitioning from a legacy system (NetSuite, SAP, Xero, QuickBooks, etc.), follow these steps in order. Completing them out of sequence can cause reconciliation problems.
Good to know: Light provides CSV import templates for most entities. Ask your implementation specialist for templates that match your legacy system's export format.
Once month-end close is complete in the legacy system, prepare frozen data packages and hand them to the implementation team:
Do not post further transactions in the legacy system after this point.
Import all unpaid invoices and bills into Light using the Migration Suspense Account (not P&L accounts). After import:
Important: Do not process payments or run bank reconciliation in Light until this step is complete. Doing so before migration is finished risks incorrect open balances.
Post the opening trial balance as of the cutoff date via:
After all imports in Steps 1 and 2 are complete, verify that the Migration Suspense Account nets to zero. A non-zero balance indicates an import discrepancy that must be resolved before go-live.
Light does not import a fixed asset register directly. Enter each fixed asset by creating a journal entry, bill, or sales invoice with a Fixed Asset release template applied on the line — Light then maintains the resulting register at (filter by Fixed asset type). Upload deferred revenue using the same release framework. Confirm that amortization logic matches your operational process.
If your entity operates in multiple currencies:
Follow these rules to maintain clean books during the transition period.
Transactions and journals
Supplier and customer invoices
Payments and bank reconciliation
Before fully cutting over to Light, run both systems in parallel:
Parallel run timeline (typically 2-4 weeks)
Processes to parallel run:
Reconciliation checklist:
If any variance exists, investigate and resolve before cutover. Most discrepancies come from:
1 week before go-live
Day of go-live
First week post-go-live
Trying to perfect everything before go-live Light can evolve post-go-live. Focus on core AR, AP, and bank functions first. Optimize reporting, revenue recognition, and multi-entity consolidation after you're stable.
Insufficient user training Users need hands-on practice before go-live. Schedule training 1-2 weeks before cutover so people remember what they learned.
Inadequate testing of approval workflows Test with real amounts and real approvers. Test edge cases: what happens if an approver is on vacation? What if an expense exceeds all thresholds?
No backup plan Have the legacy system accessible (read-only) for at least 30 days post-go-live. If a critical issue emerges, you may need to reference historical data.
Poor data quality in legacy system Spend time cleaning data before import. Bad customer names, duplicate vendors, or incorrect account codes will cause problems in Light.
Cutting over too quickly A 2-4 week parallel run is standard. Cutting over in days is risky unless you have a very simple financial structure.
After go-live stabilizes (typically 2-4 weeks), optimize:
Workflow efficiency
Automation
Reporting and dashboards
AI configuration
Team capability building
Weeks 1-4 post-go-live (Stabilization)
Weeks 4-12 post-go-live (Optimization)
Months 3+ (Sustaining)
Track these metrics post-go-live to measure success:
| Metric | Target | Measurement |
|---|---|---|
| Invoices processed daily | All > 0 days | Day count to process new invoice |
| Bills paid on time | 95%+ | Percentage paid before due date |
| Expense approval SLA | 24-48 hours | Average time from submission to approval |
| GL reconciliation completion | Daily | Days to achieve clean GL trial balance |
| Bank reconciliation | Daily/weekly | Days to complete reconciliation |
| Approval bottlenecks | < 1 per month | Escalations blocked by missing approvals |
| System uptime | 99.5%+ | Monitor dashboard availability |
Light provides support during go-live:
After successful go-live:
Was this article helpful?