Migrating Dynamics GP Fixed Assets: Data Mapping & Depreciation

GP's Fixed Asset Management module is the single most error-prone workstream in any Dynamics GP migration. It is not one table — it is a web of interdependent SQL tables spanning asset master records, multi-book depreciation schedules, GL integration accounts, retirement history, and insurance data. When you move to Business Central, NetSuite, or Sage Intacct, the target system models fixed assets differently at every layer: book structure, class hierarchy, GL posting, and depreciation calculation. (learn.microsoft.com)

Most teams should not recreate every historical depreciation line inside the new ERP. A beginning-balance or hybrid approach — migrating the asset master, active books, cutover accumulated depreciation, net book value, remaining life, and posting logic — handles the majority of cases. Full history is worth the cost only when audit, tax, or operational reporting truly requires period-by-period depreciation inside the target application.

Get the mapping wrong and your net book values will not tie, your depreciation expense will drift, and your auditors will have questions you cannot answer.

This guide covers the structural differences between GP and modern cloud ERPs, the three migration approaches and their real trade-offs, mid-year cutover mechanics, what breaks with standard tools, GL remapping, and how to extract clean data from GP's SQL database.

Microsoft has confirmed that Dynamics GP support for product enhancements, regulatory and tax updates, and technical support ends on December 31, 2029, with security updates available until April 30, 2031. If you wait too long, the people who still understand your GP fixed asset design will disappear before the data does. (learn.microsoft.com) For the broader GP sunset timeline and data strategy, see Dynamics GP End of Support 2029: What Happens to Your Data.

GP Fixed Asset Architecture: What You Are Actually Migrating

Before mapping anything, understand what GP stores and where. The Fixed Asset module uses over 20 SQL tables in the company database. The ones that matter for migration:

GP supports up to 32 books per company. A typical setup uses three: a Corporate book that posts to GL, a Federal Tax book, and an AMT book. Each book has its own depreciation method, averaging convention, switchover rules, and calendar.

GP separates policy from history. A class holds defaults, a book defines book-wide behavior, and a book-class record (FA40202) combines the two for specific depreciation logic. Microsoft's documentation describes the pattern most teams recognize: one class may have separate corporate, federal tax, and AMT book-class records, each with its own method, averaging convention, life, and tax behavior. Account groups and fixed asset posting accounts add another layer — those settings drive how asset cost, accumulated depreciation, depreciation expense, proceeds, gain/loss, and clearing accounts hit the GL. (learn.microsoft.com)

GP also stores detailed averaging conventions per asset book record — Mid-Month (15th), Mid-Month (1st), Mid-Quarter, Half-Year, Modified Half-Year, Full Month, Next Month, Full Year, and None. These conventions control when depreciation starts relative to the Place in Service Date. This detail matters because the target systems handle averaging differently — or not at all.

Data Architecture: GP vs Business Central, NetSuite, and Intacct

GP → Business Central

The structural translation is significant:

• GP Account Segments → BC Dimensions. GP uses a segmented account structure (e.g., 300-6170-00). The main account segment maps to the BC Account Number, and remaining segments become Dimensions. You choose which segments become Global Dimension 1 and Global Dimension 2 in the GP Company Migration Configuration. (learn.microsoft.com)
• GP Books → BC Depreciation Books. Each GP book (Corporate, Tax, AMT) maps to a separate BC Depreciation Book. However, BC ties depreciation books to FA Posting Groups that define the GL accounts for acquisition, accumulated depreciation, depreciation expense, and gain/loss on disposal. GP uses an Account Group per asset class (FA41300). The mapping is not direct — you must build the FA Posting Group → GL account map from scratch in BC, informed by GP's Account Group definitions.
• GP Book Class Setup → BC FA Subclass + Depreciation Book. GP's matrix of class × book depreciation rules has no direct equivalent. In BC, you set depreciation parameters (method, life, starting date) on the FA Depreciation Books page per asset, with defaults inherited from the FA Subclass.
• GP Averaging Conventions → BC Depreciation Starting Date. BC does not have an averaging convention field. You replicate GP's behavior by adjusting the Depreciation Starting Date on the FA Depreciation Book. For mid-month (15th), set it to the 15th. For full-month, set it to the 1st. BC also offers a Use Half-Year Convention toggle that gives six months of depreciation in the first fiscal year regardless of the starting date.

For a full walkthrough of the GP-to-BC data architecture, see Dynamics GP to Business Central: Migrating 20 Years of History.

GP → NetSuite

NetSuite handles fixed assets via the Fixed Asset Management (FAM) module. GP Book IDs map to NetSuite Accounting Books. GP's class structure maps loosely to Asset Types plus Custom Segments or Classifications. GP segment-based GL accounts must be translated into NetSuite's subsidiary-aware chart of accounts with departments, classes, and locations as dimensions.

Oracle's documentation is explicit on several points that affect migration design: Multi-Book Accounting lets one asset participate in multiple depreciation books, but alternate tax methods are separate from journal postings. Missing mandatory department, class, or location values can stop depreciation processing entirely. And values loaded through CSV import are not automatically posted to fixed asset GL accounts — subledger recreation and GL seeding are separate tasks. (docs.oracle.com)

When moving GP fixed assets to NetSuite, GP's FA00100 Location ID and FA00200 Account Group ID must be translated into NetSuite's Asset Types and Classifications. NetSuite's FAM module requires strict adherence to its internal depreciation history records. If you attempt to import GP depreciation history directly into NetSuite journal entries without linking them to the FAM history records, the subledger will permanently detach from the GL.

For the full NetSuite mapping, see Dynamics GP to NetSuite Migration: The CTO Guide to Data Integrity.

GP → Sage Intacct

Sage Intacct is entirely dimension-driven. The fixed asset model uses Asset Types, Depreciation Templates, and GL Account Labels. GP's book/class matrix translates to Intacct's Asset Type + Depreciation Template combinations. GP account segments become Intacct dimensions (Department, Location, Project, etc.). Sage positions its fixed asset product around dimensional tagging plus an unlimited number of financial and tax books with automatic multi-book depreciation posting. (sage.com)

Intacct handles multi-book depreciation well, but requires strict validation of the placed-in-service date against the open GL periods.

For specific Intacct mapping strategies, see Dynamics GP to Sage Intacct Migration: Data Mapping & Timeline.

Three Migration Approaches: Beginning Balance, Full History, or Hybrid

Every fixed asset migration forces a decision about how much history to carry over. There are three real options, and each has material trade-offs.

1. Beginning-Balance-Only

What moves: For each active asset, you migrate the current cost basis, accumulated depreciation (LTD), net book value, remaining useful life, and depreciation method — all as of the cutover date. No period-by-period history.

How it works: You enter each asset with an acquisition cost equal to the original cost, post accumulated depreciation as an opening balance entry, and set the depreciation starting date so the new system calculates going forward from the remaining life. Oracle's mid-life import design shows the required precision: fields like Depreciation Start Date, Last Depreciation Date, Last Depreciation Period, Last Depreciation Amount, and Current Net Book Value all matter, and Oracle warns that wrong values can cause skipped periods. (docs.oracle.com)

When to use it:

• You do not need period-by-period depreciation detail in the new system
• You plan to retain GP (or a GP SQL archive) for historical lookback
• You want the fastest possible cutover

Risks:

• No drill-down into historical depreciation in the new ERP
• If accumulated depreciation in GP is wrong (due to skipped resets, manual overrides, or rounding drift), you carry the error forward
• Auditors may question the opening balance without a clear chain-of-custody document tying GP's closing balances to the new system's opening entries

2. Full History

What moves: Every acquisition entry, every period-by-period depreciation amount, every adjustment, every retirement, and every transfer — reconstructed in the new ERP's ledger.

How it works: You extract the complete depreciation schedule from GP's FA00902 table, transform each period's depreciation into the target ERP's journal entry format, and post them chronologically. This is the only approach that gives you native drill-down into historical depreciation in the new system.

For NetSuite, Oracle is explicit that mid-life assets can include several depreciation history records and that a depreciation history record is required for every depreciation entry you want represented. Oracle is also explicit that imported asset values are not automatically posted to fixed asset GL accounts, so subledger recreation and GL seeding are separate tasks. (docs.oracle.com)

For Business Central, plan for a custom workstream. Microsoft's public migrated-data list does not name fixed assets among the standard GP-to-BC migration objects. (learn.microsoft.com)

When to use it:

• Regulatory or audit requirements demand period-level depreciation detail in the system of record
• You are decommissioning GP entirely and cannot maintain an archive
• Management needs historical depreciation reports from the new ERP for trend analysis

Risks:

• Significantly more complex and time-consuming to execute
• The target ERP's depreciation engine may calculate slightly different amounts than GP for the same parameters (BC defaults to 360-day years; GP uses its own fiscal calendar)
• High risk of GL imbalance — if the target system calculates fractions of a cent differently than GP did years ago, the subledger will not tie to the GL
• We generally advise against full history unless strictly required by regulatory compliance

3. Hybrid (Recommended for Most Migrations)

What moves: Beginning balances as of the cutover date into the active fixed asset module for go-forward calculations, plus the complete GP fixed asset history preserved in a queryable reporting layer.

How it works: You enter opening balances in the new ERP. Simultaneously, you extract the complete GP fixed asset history and load it into a queryable archive — a SQL database, Azure Data Lake, Snowflake, or similar — accessible via reporting tools like Power BI. This keeps the new ERP clean while satisfying auditors. Some organizations bring a limited window of recent period-by-period detail (last 2–3 years) directly into the target system for native reporting, while archiving older history externally.

When to use it:

• You need recent audit-period detail but do not need 15 years of monthly depreciation in the new system
• You are archiving older GP data for IRS retention requirements

Most controllers end up here. Choose beginning-balance-only when the business mainly needs accurate forward depreciation and clean day-one operations. Choose full history only when auditors, tax workflows, or downstream reporting require in-app historical schedules. Choose hybrid when the business wants recent detail available without bloating the live FA register.

Fully Depreciated Assets: Migrate or Leave Behind?

GP environments running for 15–25 years often contain hundreds or thousands of fully depreciated assets still marked as "in service." These assets have a net book value of zero and will never generate another depreciation entry. But they may represent physical equipment, furniture, or vehicles that the company still uses and tracks.

Migrate them: The new FA register gets cluttered with zero-value records. Every depreciation run touches them (even if the calculated amount is zero). Reporting includes them unless you filter. But you retain a complete physical asset inventory in one system.

Leave them behind: The new system stays clean. But you lose physical asset tracking unless you maintain a separate inventory — either in a queryable GP archive or a standalone asset-tracking tool.

Our recommendation: If the organization uses fixed assets for physical inventory tracking, insurance, or property tax reporting, migrate fully depreciated assets but tag them with a distinct FA Subclass or custom field in the target ERP so they can be filtered out of financial reports. If fixed assets are tracked purely for depreciation, leave them in the archive.

Handling Mid-Year Migrations and Partial Depreciation

If you cut over on January 1st, the math is simple. Most GP migrations do not land neatly on a fiscal year boundary. A mid-year cutover — say, July 1 — means depreciation for the current fiscal year is split across two systems: GP handles the first half, the new ERP handles the second.

This creates three specific problems.

1. YTD depreciation already taken in GP must not be duplicated. Before extracting data, run depreciation in GP through the last period before cutover. Then pull the YTD Depreciation and LTD Depreciation amounts from FA00200. In the target ERP, post accumulated depreciation (including the current-year amount already taken) as an opening balance, and set the Depreciation Starting Date to the first day of the next period.

2. GP's averaging conventions do not translate directly. GP uses the Averaging Convention field on the Asset Book record to determine when depreciation starts. BC has no equivalent field — you must translate the convention into a specific Depreciation Starting Date. For example, if GP used Mid-Month (15th) and the asset was placed in service on March 22, GP started depreciation on March 15. In BC, set the Depreciation Starting Date to March 15 to match. Microsoft's Half-Year Convention toggle in BC ignores the Depreciation Starting Date for the first-year amount and requires a specific Depreciation Ending Date alignment — so if your GP books use mid-month or half-year behavior, you must map convention logic, not just dates. (learn.microsoft.com)

3. Day-count differences between systems. BC defaults to a 360-day year with 30-day months. GP uses its own fiscal calendar, which may have 365-day years. If GP's Corporate book used calendar-day calculations, enable the Fiscal Year 365 Days toggle on the BC Depreciation Book Card to match. Failing to align this will produce a small but compounding drift in depreciation amounts. NetSuite is equally unforgiving — Oracle's mid-life import relies on Depreciation Start Date, Last Depreciation Date, Last Depreciation Period, Last Depreciation Amount, and Current NBV, and warns that wrong date or period values can make assets skip depreciation entirely. (docs.oracle.com)

Recalculating GP Before Export

If any fixed assets were revalued or had depreciation-sensitive fields changed in GP — cost basis, depreciation method, original life, place in service date, salvage value — you must run the appropriate reset routine before extraction. Microsoft documents three options: Recalculate (adjusts the go-forward rate only), Reset Year (recalculates from the beginning of the current fiscal year), and Reset Life (recalculates from the Place in Service date through the current depreciated-to date). (learn.microsoft.com)

Navigate to Cards → Fixed Assets → Book, select the asset and book, and choose the appropriate routine. Use Reset Life to ensure LTD depreciation is accurate before export.

The Cutover Manifest

Build this file per asset, per book before loading the target system:

asset_id,book_id,target_book,method,convention,acquisition_date,depr_start_date,last_depr_date,acquisition_cost,accum_depr_cutover,nbv_cutover,remaining_life_months,posting_group_or_asset_type,gl_asset_account,gl_accum_depr_account,gl_depr_expense_account,department,location,insurance_policy,status
FA-000123,CORP,MAIN,SL,Mid-month,2022-03-17,2022-03-16,2026-06-30,120000,64000,56000,28,EQUIP,1500,1590,6100,OPS,DEN-01,PROP-07,In service

If that file does not exist, you do not have a migration design yet. You have source data.

What Breaks with Standard Migration Tools

Microsoft Cloud Migration Tool

The Microsoft Cloud Migration Tool is the native path for moving GP data to Business Central. It handles GL summary transactions, customer/vendor master data, and open documents reasonably well. Fixed assets are a different story.

The tool moves GP Fixed Asset tables to a custom table range in BC. The data is not mapped to BC's standard Fixed Asset tables (the Fixed Asset card, FA Depreciation Books, FA Ledger Entries). After migration, your fixed assets exist in BC only as raw data in extension tables — not as functional FA cards with depreciation books, posting groups, and GL integration. Microsoft's public migrated-data documentation lists fiscal periods, chart of accounts, customers, vendors, inventory, and checkbooks, but does not name fixed assets among the standard GP-to-BC migration objects. (learn.microsoft.com)

To turn that raw data into working BC fixed assets, you need a separate mapping and transformation step — typically custom AL scripts. It is not a turnkey solution.

Specific limitations:

• No averaging convention translation. The tool does not convert GP's averaging conventions into BC Depreciation Starting Dates.
• No multi-book reconciliation. The tool does not validate that the sum of depreciation across all books ties to the GL accounts.
• No period-by-period depreciation import. The tool moves summary GL balances, not the granular depreciation schedule from FA00902.
• No handling of Extender or add-on data. GP customizations using Extender tables, third-party ISV add-ons, or custom fields attached to fixed assets are not migrated. These must be mapped manually or rebuilt.

Extender Tables and Customizations

If your team used eOne Solutions' Extender or other third-party add-ons to add custom fields to GP Fixed Assets (vehicle VINs, specialized insurance tracking, grant funding codes), those fields reside in separate SQL tables outside the core FA schema. Standard migration tools ignore these tables entirely. You must write custom SQL scripts to join the Extender tables to the core FA00100 master records before extraction.

Audit those dependencies early with How to Audit Dynamics GP Customizations Before Migration.

DIY CSV Work

Microsoft's own import guidance for GP warns not to use Table Import for asset information, notes that Excel can strip leading zeros from asset IDs, documents that retired assets cannot be imported as retired, and states that import failures can force restores or cleanup before reruns. CSV is fine as a staging format. It is not a depreciation strategy. (learn.microsoft.com)

For a broader look at the failure patterns in ERP data migrations, see Why ERP Migrations Fail at the Data Layer: 9 Core Patterns.

GL Integration: Remapping Posting Accounts

GP's Fixed Asset module posts to GL through a tightly coupled system of Account Groups (FA41300) and FA-AP Post Accounts. The Corporate book posts depreciation expense, accumulated depreciation, gain/loss on disposal, and clearing account entries to specific GL accounts defined per asset class.

In Business Central, this mapping is handled by FA Posting Groups. Each FA Posting Group defines the GL accounts for acquisition cost, accumulated depreciation, and depreciation expense. Every FA card is linked to one FA Posting Group.

The migration step most teams skip: building a crosswalk from GP Account Groups to BC FA Posting Groups, validated against the new chart of accounts. This crosswalk must account for the fact that GP's segmented GL accounts are now dimension-coded single-segment accounts in BC. A GP depreciation expense account of 300-6170-02 becomes BC Account 6170 with Department dimension 300 and Division dimension 02 — but the FA Posting Group only references the account number. The dimensions must be set separately on the FA journal lines or through allocation keys.

In NetSuite and Intacct, the same decomposition applies: GP's single account group concept must be split into the target system's posting controls, reporting classifications, and dimensional tags. Decide early whether GP account segments become reporting dimensions, posting classifications, both, or neither. If you leave that until import week, you will be fixing depreciation errors with journals instead of design.

How ClonePartner Handles GP Fixed Asset Migrations

We extract fixed asset data directly from GP's SQL database — FA00100, FA00200, FA00400, FA00902, and the full setup table chain. We treat fixed asset migrations as a strict engineering discipline, not a CSV exercise.

Our approach breaks into five layers so finance can sign off each one independently:

1. Extract: Pull asset master, asset book, depreciation state, account mapping, location, insurance, transfer, and retirement data from GP SQL — including any Extender or ISV custom tables joined to the core FA records.
2. Transform: Convert GP account segments into Business Central Dimensions, NetSuite Classifications, or Sage Intacct Dimensions programmatically. Split GP book-class logic into target depreciation books, posting groups, and asset types.
3. Validate: Calculate and validate partial-year depreciation for mid-year cutovers, ensuring the target ERP's depreciation engine picks up exactly where GP left off. Generate book-level reconciliation reports proving the numbers tie.
4. Load: Import into the target system using its native behavior — BC depreciation books and FA posting groups, NetSuite FAM records and GL seeding, Intacct asset types and depreciation templates — rather than forcing GP semantics into the wrong fields.
5. Reconcile: Prove asset count, acquisition cost, accumulated depreciation, and current NBV by book before go-live.

The load layer changes by target. In NetSuite, asset import, depreciation history import, and GL posting are separate concerns. In Business Central, depreciation books, FA posting groups, and dimension mapping are separate configuration objects. In Sage Intacct, dimensions and multi-book depreciation are native parts of the model. A reusable extraction and transformation core plus target-specific loaders works better than one giant CSV template.

The Decision That Matters

Before starting your fixed asset migration, answer these five questions:

1. How many active books do you use? If only Corporate posts to GL, the Tax and AMT books may be candidates for archive-only treatment.
2. Do you need period-by-period depreciation in the new ERP? If yes, plan for a full or hybrid migration. If no, beginning-balance-only is faster and lower risk.
3. When is your cutover date? A fiscal year-end cutover eliminates the partial-year problem entirely. Mid-year cutovers add significant effort to the fixed asset workstream.
4. How many fully depreciated assets are in service? If the number is large (500+), decide upfront whether to migrate or archive them. This affects your FA register size, reporting, and data load time.
5. Are there Extender or ISV customizations on fixed assets? If yes, budget time to map custom fields manually. No standard tool migrates them.

Do not ask whether you can export GP fixed assets. You can. Ask whether the new ERP will calculate the same next depreciation run, post it to the right accounts, and preserve the audit trail you actually need. If the answer is not demonstrably yes, the migration design is not finished.

The fixed asset module is where ERP migrations earn or lose credibility with the finance team. Get the depreciation right, tie the numbers to GL, and document the chain of custody — and the rest of the migration feels easy by comparison.