← All guides

General Ledger Conversion Project Timeline

Manage a general ledger conversion with a project timeline covering data mapping, historical migration, chart of accounts redesign, and cutover planning.

General Ledger Conversion Project Timeline

GL Conversions Go Wrong at Data Mapping, Not at Go-Live

The most common failure in a GL conversion is discovered post-cutover: account mapping errors that cause financial statements to not tie, historical data that doesn't reconcile, or journal entries that hit the wrong account because the crosswalk table was built incorrectly.

These problems aren't caused by bad technology or poor implementation. They're caused by underinvesting in Phase 4 — data migration planning — and rushing through the trial migrations that would have caught errors before they made it to production. Every GL conversion project should run 3–5 trial migrations and reconcile each one completely before committing to cutover. Here's the full project structure.

Phase 1: Discovery and Scoping (Months 1–2)

Before any design work, understand what exists and what's required.

Current state documentation:

  • Extract complete chart of accounts with account numbers, descriptions, and account types
  • Document the segment structure: how are dimensions currently captured (department, location, project)?
  • Identify the number of active vs. inactive accounts (accounts with zero balance and no activity in 2+ years)
  • Measure transaction volume: average monthly journal entry line items across all entities
  • Document integration points: payroll, AP, AR, fixed assets, expense management, bank feeds

Reporting requirements (the driver of design):

  • What does the CFO see in the monthly management pack? What level of detail?
  • What does the board see? What does it not see?
  • What regulatory or external reporting requirements exist?
  • What does FP&A need for budget-to-actuals? At what granularity?

Data migration scope decision:

  • Full transaction history: all periods since company inception (longest migration, most complex)
  • Defined history: last 2–3 years of transactions plus current year (recommended for most companies)
  • Summary balances only: opening balances by account with no historical transaction detail
  • The right choice depends on audit requirements, reporting needs, and migration complexity

Phase 2: New GL Design (Months 2–3)

Design the target state before touching any system.

Chart of accounts design:

  • Natural accounts: describe the economic nature of the item (not the business unit or location)
  • Account ranges: standardize ranges by category
  • 1000–1999: Assets
  • 2000–2999: Liabilities
  • 3000–3999: Equity
  • 4000–4999: Revenue
  • 5000–5999: Cost of goods sold
  • 6000–7999: Operating expenses
  • 8000–8999: Non-operating income/expense
  • Reserve ranges within each band: don't number consecutively — leave gaps for future accounts

Segment structure design:

  • Entity/company: legal entity for consolidation
  • Department: organizational unit for cost allocation
  • Location: geographic or facility dimension
  • Project/job: project-level tracking where needed
  • Product: for product-level P&L

The segment structure carries dimensional reporting. Natural accounts should not encode dimensions (don't have "Software Expense — Engineering" as an account; have "Software Expense" as the account and "Engineering" as the department segment).

Account crosswalk:

  • Map every existing account to one or more new accounts
  • Flag many-to-one mappings (multiple old accounts → single new account) and one-to-many (old account splits)
  • One-to-many mappings require a distribution rule: how to split historical transactions
  • Get stakeholder sign-off on the crosswalk before moving to system configuration

Phase 3: System Configuration (Months 3–4)

Configure the new GL in the target system.

Tasks:

  • Create all new accounts per the approved chart of accounts
  • Configure segment values: all entity codes, department codes, location codes
  • Set up intercompany relationships and elimination rules
  • Configure fiscal calendar and period structure
  • Set up currency settings for multi-currency entities
  • Configure journal entry approval workflow
  • Set up financial report templates: P&L, balance sheet, cash flow, by entity

Test the configuration with a small batch of manually-created journal entries before importing any migrated data.

Phase 4: Data Migration Planning (Months 3–5)

This phase runs in parallel with configuration and is the most technically demanding.

Extract:

  • Pull full transaction history from the legacy system for the agreed scope period
  • Export in the most granular format available: journal entry line level, not summarized
  • Include all fields: date, period, account, amount, description, reference, department, any other segments

Transform:

  • Apply the crosswalk table: convert every old account number to the new account number
  • Map old segments to new segment structure
  • Convert date formats, currency codes, and any other structural differences
  • Flag transactions that can't be mapped automatically (these require manual review)

Data quality remediation:

  • Transactions with accounts that don't exist in the crosswalk
  • Transactions with departments that don't exist in the new segment structure
  • Transactions with missing required fields
  • Transactions in closed periods that need special handling

Phase 5: Migration Testing (Months 5–6)

Run trial migrations until the data is clean. Do not skip this phase.

Trial migration 1:

  • Load transformed data into test environment
  • Run trial balance in new system and compare to trial balance from legacy system by period
  • Identify discrepancies: account balance differences, missing transactions, misclassified items
  • Document all exceptions

Fix and repeat:

  • Update crosswalk table to address mapping errors
  • Fix data quality issues in the transformation scripts
  • Run trial migration 2, reconcile again
  • Repeat until trial balance ties within an acceptable tolerance (typically $0 or <$100)

Three to five trial migrations is normal. The first trial migration almost always has significant exceptions. By trial 3 or 4, you should be reconciling to zero or near-zero. If exceptions persist after 4 trials, escalate — there may be a fundamental mapping error.

Phase 6: Parallel Processing (Month 6–7)

Post transactions in both systems simultaneously for one full period.

  • All new journal entries go into both legacy and new GL
  • Reconcile weekly: new GL trial balance should match legacy GL trial balance
  • Track discrepancies and resolve before cutover
  • Use parallel processing results to validate all integration feeds: payroll, AP, AR should all post consistently in both systems

Phase 7: Cutover (Month 7–8)

Cutover weekend:

  • Freeze all posting in legacy GL at close of business Friday
  • Run final migration of any transactions posted since the last trial migration
  • Post opening balances in new GL if using summary balance migration approach
  • Validate new GL trial balance against legacy GL trial balance one final time
  • Open new GL for posting on Monday

Post-cutover:

  • Monitor for misdirected transactions in the first close cycle
  • Validate financial statements reconcile to prior period using legacy data
  • Close legacy system to new posting (read-only access for reference)

Build the complete GL conversion timeline in gantt-chart.io, with Phase 5 (migration testing) as a multi-iteration loop and the cutover weekend marked as a milestone. Share the timeline with the external auditors — they'll want visibility into the conversion approach and reconciliation process for their audit procedures.