// Source System
BPCS to Dynamics 365 Data Migration
We've moved General Ledger and inventory data out of BPCS into D365 F&O — cleanly, completely, on time.
BPCS — Entity Mapping
// The Challenge
Why BPCS migrations are hard.
BPCS (Business Planning and Control System) runs on the IBM AS/400 (IBM i) platform, and most implementations we encounter have little to no modern API surface. Data extraction typically means working with flat-file exports or direct reads against the DB2 database underneath, which requires AS/400-literate technical resource on the discovery side.
Because BPCS installations are often decades old, customisations accumulate in ways that aren't always documented — custom fields bolted onto standard structures, or entire modules replaced with bespoke logic. Discovery has to include a genuine audit of what the live system actually contains, not just what the original implementation specification said.
General ledger and inventory data volumes in long-running BPCS environments can be substantial, and historical transaction detail is often only available through report extracts rather than clean table dumps, which shapes how much history is practical to bring forward versus summarise at migration.
// Mapping
BPCS entities, mapped to D365.
| Source entity | D365 entity |
|---|---|
| Customer master file | CustTable |
| Vendor master file | VendTable |
| GL account master & transactions | MainAccount / GeneralJournalAccountEntry |
| Item master file | InventTable |
// Pitfalls
Where BPCS migrations go wrong.
- Limited or no API access means extraction usually relies on flat-file exports or direct DB2 reads — confirm access method during discovery, not during build.
- Undocumented customisations are common in long-running BPCS environments — profile the live system rather than trusting original specs.
- Historical transaction detail is often only available via report extracts, not clean tables — decide what history is practical to migrate versus summarise.
- AS/400-literate technical resource is usually needed on the source side — factor this into discovery timelines.
// Domains
Domains we most commonly migrate from BPCS.
// Methodology
The same six phases, every time.
01
DISCOVER
Profiling, volumes, quality scoring across every source system in scope.
02
DESIGN
Source-to-target mapping and the cleansing plan, agreed before build starts.
03
BUILD
DMF templates, KingswaySoft packages, SQL staging tables.
04
TEST
Two mock migrations, full reconciliation, and UAT sign-off.
05
CUTOVER
Final load, balance reconciliation, go-live clearance.
06
STABILISE
Corrections, closure report, retainer option for what follows.
// FAQ
Questions about migrating from BPCS.
Typically via flat-file exports or direct DB2/AS400 reads, coordinated with whoever currently administers the environment.
Planning a BPCS to D365 migration?
Start with a Health Check to see exactly what needs cleansing before it moves.