ERP migration
Field-level mapping, validation, and rollback between Aqilla and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
Aqilla
Source
Epicor Prophet 21
Destination
Compatibility
13 of 14
objects map 1:1 between Aqilla and Epicor Prophet 21.
Complexity
BStandard
Timeline
4-8 weeks
Overview
Moving from Aqilla to Epicor ERP is a shift from a finance-led, multi-entity consolidation platform to a manufacturing-led ERP that embeds finance within its operational modules. Aqilla organises data around hierarchical account structures with 20+ Analysis Codes per transaction; Epicor organises around Part, Job, and Product structures with GL Account configured within each operational module. We resolve the account mapping during scoping, decompose inter-company journals into individual entity postings with elimination entries where Epicor's consolidation model differs, and carry forward all FX and multi-currency fields through the migration. Epicor does not have a native Making Tax Digital equivalent; MTD submission history migrates as archived records and the customer confirms any live HMRC obligations before cutover. Workflows, payment runs configured in Aqilla, and MTD filing integrations do not migrate; we deliver a written inventory of these for the customer's Epicor admin to rebuild.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Aqilla object lands in Epicor Prophet 21, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Aqilla
Chart of Accounts
Epicor Prophet 21
GL Account
1:1Aqilla's hierarchical account structure maps to Epicor GL Account records with account codes preserved where possible. Analysis Codes (up to 20+ per transaction in Aqilla) require mapping to Epicor's cost dimension model. We capture the full account hierarchy during discovery and produce a matrix mapping each Aqilla account code and analysis code to the equivalent Epicor GL Account or cost dimension field. Where the destination uses a flatter chart, we collapse the hierarchy into parent-level accounts and flag the dimensional detail for the customer's admin to configure in Epicor's reporting layer.
Aqilla
Journal Entries (Header + Lines)
Epicor Prophet 21
GL Journal Entry
1:1Aqilla journal entries consist of a header with effective date and reference number, and line-level debits and credits with analysis codes. We migrate all posted journals with their effective dates, reference numbers, and line-level amounts. Unposted journals require period-status coordination before migration; we extract a period-status checkpoint and carry forward any late adjustments as a post-migration journal batch. Epicor's journal entry model requires a fiscal period to be open before posting; we coordinate with the customer's Epicor admin to confirm period-status settings at each phase.
Aqilla
Multi-Company and Inter-Company Journals
Epicor Prophet 21
Separate GL Journal Entries with Elimination Entries
many:1Aqilla's multi-entity mode posts inter-company journals that cross-reference two or more entities in a single transaction. Epicor does not natively support inter-company journal posting across separate company codes in the same transaction. We decompose each inter-company journal into individual entity-level journal entries and generate elimination entries to zero out the inter-company balance. The elimination logic is documented and validated against the group-level trial balance post-load.
Aqilla
Customer / Accounts Receivable
Epicor Prophet 21
Customer
1:1Aqilla customer records include contact details, currency settings, credit limits, and tax registration. We map customer records to Epicor Customer, preserving credit limit, payment terms, and currency settings. Open AR invoices migrate as Epicor AR Invoice records with line-item detail. Multi-currency customer settings carry forward where Epicor's currency configuration supports the same currency set.
Aqilla
Vendor / Accounts Payable
Epicor Prophet 21
Supplier
1:1Aqilla vendor records include multi-currency settings, payment terms, and tax codes. We map vendor records to Epicor Supplier, preserving payment terms and tax registration. Purchase invoices and credit notes migrate as Epicor AP Invoice records with full line-item detail. Epicor's supplier model supports the same multi-currency and tax code structures used in Aqilla.
Aqilla
Purchase Invoices (Header + Lines)
Epicor Prophet 21
AP Invoice with Line Detail
1:1Aqilla exposes container/subordinate invoice structures natively via its API. We extract purchase invoice headers and all associated lines, preserving quantity, unit price, tax code, and analysis codes on each row. Epicor AP Invoice records are created with matching line-level detail. Invoice status (posted, unposted) maps to Epicor's AP Invoice approval workflow, and any AQILLA-specific approval routing is documented for rebuild in Epicor.
Aqilla
Sales Invoices
Epicor Prophet 21
AR Invoice with Line Detail
1:1Order-to-cash invoices including line items, tax breakdown, and payment terms migrate with full header and subordinate detail preserved to Epicor AR Invoice. Epicor's AR Invoice model requires a customer and invoice date; we map these from the Aqilla invoice header and preserve the original transaction reference for audit. Tax breakdown migrates to Epicor's Tax Detail records.
Aqilla
Fixed Assets
Epicor Prophet 21
Asset with Depreciation Schedule
1:1Aqilla asset records include acquisition date, cost, depreciation method, and book values. We map depreciation schedules to Epicor's Asset module and flag any mid-period acquisitions for period-adjusted depreciation entry. Where Aqilla uses a depreciation method not natively supported in Epicor, we document the method and carry the book value schedule for manual configuration post-migration.
Aqilla
Inventory Items
Epicor Prophet 21
Part with Inventory Records
1:1Aqilla inventory items include stock valuation, costing method, and on-hand quantities. We migrate item definitions and current stock positions to Epicor Part records with PartBin entries for warehouse locations. Epicor's PartTran transaction history does not carry forward; open purchase orders and sales commitments migrate as Epicor PO and SO records, and the customer reviews any partially-received or partially-shipped orders before cutover.
Aqilla
Bank Accounts and Reconciliations
Epicor Prophet 21
Bank Account with Cash Flow
1:1Aqilla maintains bank accounts with imported transactions, cash matching, and bank reconciliation workflows. We carry over reconciled and unreconciled positions and flag unmatched items for re-reconciliation in Epicor. Epicor's cash management module requires bank account configuration including bank code and currency; we map these from the Aqilla bank account setup.
Aqilla
Tax Codes and MTD Submissions
Epicor Prophet 21
Tax Code with Manual Submission
1:1Tax codes migrate to Epicor Tax Code records with the same rates and jurisdictions. Aqilla's Making Tax Digital submission history migrates as an archive of submission records. Epicor does not have a native MTD API integration; the customer confirms any live HMRC obligations before migration and documents any third-party MTD filing tool they plan to use post-migration.
Aqilla
Users and Roles
Epicor Prophet 21
Epicor User with Security
1:1Aqilla assigns users to Core, Business, Pro, or Enterprise seat types with feature access gated by tier. We capture the full user-role inventory before migration and produce a role-mapping matrix to Epicor's user security model. Epicor uses company-code-level and module-level permissions; we map Aqilla's area-level permissions to the nearest Epicor security configuration and flag any access patterns that cannot be directly reconstructed.
Aqilla
Budgets and Forecasts
Epicor Prophet 21
GL Budget Records
1:1Aqilla budget versions and forecast models store calculation logic specific to its reporting engine. We extract the latest approved budget values and migrate them as Epicor GL Budget records with period granularity. Budget formulas and forecast models that rely on Aqilla-native calculation logic are converted to destination formula equivalents where supported, and the customer receives a written inventory of any budget models that cannot be fully reconstructed from the raw data alone.
Aqilla
Attachments and Documents
Epicor Prophet 21
Document Management
1:1Aqilla provides unlimited file storage and automated document delivery. We extract linked documents by transaction reference and re-associate them with the corresponding Epicor record where the document management system supports the same file type and reference linkage. Epicor's DocStar ECM integration or native document storage receives the migrated files; we flag any attachments that cannot be linked programmatically and provide a file-indexed handoff for manual re-association.
| Aqilla | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Chart of Accounts | GL Account1:1 | Fully supported | |
| Journal Entries (Header + Lines) | GL Journal Entry1:1 | Fully supported | |
| Multi-Company and Inter-Company Journals | Separate GL Journal Entries with Elimination Entriesmany:1 | Fully supported | |
| Customer / Accounts Receivable | Customer1:1 | Fully supported | |
| Vendor / Accounts Payable | Supplier1:1 | Fully supported | |
| Purchase Invoices (Header + Lines) | AP Invoice with Line Detail1:1 | Fully supported | |
| Sales Invoices | AR Invoice with Line Detail1:1 | Fully supported | |
| Fixed Assets | Asset with Depreciation Schedule1:1 | Mapping required | |
| Inventory Items | Part with Inventory Records1:1 | Mapping required | |
| Bank Accounts and Reconciliations | Bank Account with Cash Flow1:1 | Fully supported | |
| Tax Codes and MTD Submissions | Tax Code with Manual Submission1:1 | Fully supported | |
| Users and Roles | Epicor User with Security1:1 | Mapping required | |
| Budgets and Forecasts | GL Budget Records1:1 | Mapping required | |
| Attachments and Documents | Document Management1:1 | Mapping required |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Aqilla gotchas
API is an add-on gated behind Enterprise tier
Multi-company and inter-company journals require sequencing
User seat tiers do not directly map to destination role models
Open journal periods must be closed before final cutover
Budgets and forecast models use Aqilla-native formulas
Epicor Prophet 21 gotchas
Third-party bolt-on integrations complicate migration scope
Dirty data without standardized processes compounds migration risk
SDK customizations and BPMs may not survive platform upgrades
Report-based export only for non-technical users
Per-user pricing model requires accurate user count before migration planning
Pair-specific challenges
Migration approach
Discovery and source audit
We audit the source Aqilla tenant across tier (Core/Business/Pro/Enterprise), entity count, chart of accounts size, transaction volumes by type (journals, invoices, payments), multi-currency settings, open period status, inter-company journal frequency, and attachment volume. We confirm API access entitlement (Enterprise add-on) and scope the CSV export approach where API access is unavailable. The discovery output is a written migration scope, entity mapping table, and account-to-dimension mapping matrix draft.
Schema design and account mapping
We design the Epicor schema in a non-production environment. This includes provisioning GL Accounts (mapped from the Aqilla chart of accounts with analysis codes resolved to cost dimensions), configuring AP and AR modules with customer and supplier records, setting up fiscal calendar periods, configuring tax codes, and mapping the multi-company entity structure. The account-to-dimension mapping matrix is validated against the top 50 transactions in Aqilla before the migration script is written.
Sandbox migration and reconciliation
We run a full migration into Epicor using production-like data volume. The customer's finance lead reconciles GL balances (trial balance in, trial balance out), open invoice counts (AP and AR), customer and vendor record counts, and fixed-asset book values against the Aqilla source. Spot-checks on 25-50 random journal entries verify effective date, amount, and analysis code accuracy. Any mapping corrections are applied to the migration script before production migration begins.
Inter-company journal decomposition
We extract all inter-company journals from Aqilla, decompose each into individual entity-level postings, and generate elimination entries to zero out the inter-company balance in the consolidated view. The decomposition logic is documented and the elimination entries are validated against the group-level trial balance. This step runs as a separate transform before the main journal migration batch and is reviewed by the customer's consolidation team before approval to proceed.
Production migration in dependency order
We run production migration in record-dependency order: GL Accounts (with cost dimension mapping), Fiscal Calendar periods, Customers and Suppliers, Fixed Assets with depreciation schedules, AP and AR invoices with line detail, Bank accounts and cash positions, Journal entries, Budget data, and finally attachments. Open-period status is confirmed with the customer before each journal batch runs. Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, validation, and handoff
We freeze Aqilla writes during cutover, run a final delta migration of any records modified during the migration window, then enable Epicor as the system of record. We validate the post-migration trial balance against the final Aqilla report, confirm open invoice aging in both AP and AR, and deliver the inter-company elimination documentation, MTD submission archive, and any budget model inventory requiring manual rebuild. We support a one-week hypercare window where we resolve any reconciliation issues. We do not rebuild Aqilla payment runs, approval workflows, or MTD integrations; these are documented for the customer's Epicor admin to configure.
Platform deep dives
Aqilla
Source
Strengths
Weaknesses
Epicor Prophet 21
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Aqilla and Epicor Prophet 21.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Aqilla: Not publicly documented.
Data volume sensitivity
Aqilla doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Aqilla to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your Aqilla to Epicor Prophet 21 migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Aqilla
Other ways to arrive at Epicor Prophet 21
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.