ERP migration

Migrate from Aqilla to Epicor Prophet 21

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 logo

Aqilla

Source

Epicor Prophet 21

Destination

Epicor Prophet 21 logo

Compatibility

93%

13 of 14

objects map 1:1 between Aqilla and Epicor Prophet 21.

Complexity

BStandard

Timeline

4-8 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Aqilla logo

Aqilla

What's pushing teams away

  • Aqilla is perceived as expensive relative to competing ERPs, with per-user pricing that scales significantly at the Business and Pro tiers.
  • User permission configuration is described as confusing — controlling access at granular object and area levels requires effort to get right.
  • Some customers report that development requests for fine-tuning or bug fixes take extended time to address after the first year of use.
  • Organisations with simple, single-entity requirements find the multi-company and analysis-code complexity unnecessary overhead for their use case.

Choosing

Epicor Prophet 21 logo

Epicor Prophet 21

What's pulling them in

  • Industry-specific design for wholesale distributors, not a general-purpose ERP repurposed for distribution — distributors choose P21 because it matches their replenishment, kitting, and counter-sale workflows out of the box.
  • Strong inventory control with automated replenishment, lot and serial tracking, and multi-warehouse management appeals to distributors with complex stock requirements and tight margin pressure.
  • Responsive customer support cited across G2 and Gartner reviews, with Epicor's 90% retention rate reflecting long-term customer satisfaction in a market where switching costs are high.
  • Cloud deployment on Microsoft Azure provides the flexibility to scale user counts and warehouse locations without on-premise infrastructure investment.
  • The Software Development Kit lets distributors personalize P21 to their specific business processes without modifying the application source code, preserving upgrade paths.

Object mapping

How Aqilla objects map to Epicor Prophet 21

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

maps to

Epicor Prophet 21

GL Account

1:1
Fully supported

Aqilla'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)

maps to

Epicor Prophet 21

GL Journal Entry

1:1
Fully supported

Aqilla 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

maps to

Epicor Prophet 21

Separate GL Journal Entries with Elimination Entries

many:1
Fully supported

Aqilla'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

maps to

Epicor Prophet 21

Customer

1:1
Fully supported

Aqilla 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

maps to

Epicor Prophet 21

Supplier

1:1
Fully supported

Aqilla 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)

maps to

Epicor Prophet 21

AP Invoice with Line Detail

1:1
Fully supported

Aqilla 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

maps to

Epicor Prophet 21

AR Invoice with Line Detail

1:1
Fully supported

Order-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

maps to

Epicor Prophet 21

Asset with Depreciation Schedule

1:1
Mapping required

Aqilla 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

maps to

Epicor Prophet 21

Part with Inventory Records

1:1
Mapping required

Aqilla 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

maps to

Epicor Prophet 21

Bank Account with Cash Flow

1:1
Fully supported

Aqilla 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

maps to

Epicor Prophet 21

Tax Code with Manual Submission

1:1
Fully supported

Tax 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

maps to

Epicor Prophet 21

Epicor User with Security

1:1
Mapping required

Aqilla 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

maps to

Epicor Prophet 21

GL Budget Records

1:1
Mapping required

Aqilla 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

maps to

Epicor Prophet 21

Document Management

1:1
Mapping required

Aqilla 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.

Gotchas + challenges

What specifically takes care here

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 logo

Aqilla gotchas

High

API is an add-on gated behind Enterprise tier

High

Multi-company and inter-company journals require sequencing

Medium

User seat tiers do not directly map to destination role models

Medium

Open journal periods must be closed before final cutover

Low

Budgets and forecast models use Aqilla-native formulas

Epicor Prophet 21 logo

Epicor Prophet 21 gotchas

High

Third-party bolt-on integrations complicate migration scope

High

Dirty data without standardized processes compounds migration risk

Medium

SDK customizations and BPMs may not survive platform upgrades

Medium

Report-based export only for non-technical users

Low

Per-user pricing model requires accurate user count before migration planning

Pair-specific challenges

  • Aqilla REST API is gated behind Enterprise tier

    Aqilla does not expose its REST API on all plans. API Integration is listed as a paid add-on and the Enterprise tier (£92/user/month) is required to access it at all. Customers on Core, Business, or Pro who want to export data programmatically cannot do so without purchasing an upgrade. We scope the migration by requesting CSV exports from the UI where API access is unavailable, and we confirm API entitlement during discovery to avoid surprises. Where CSV exports are used, we validate field completeness against the API data model before committing to the migration approach.

  • Finance-led to manufacturing-led schema shift requires account mapping

    Aqilla is organised around a hierarchical Chart of Accounts with Analysis Codes attached to every transaction. Epicor ERP is organised around Part, Job, and Product structures with GL Accounts configured within operational modules. There is no direct 1:1 mapping between Aqilla's analysis dimension model and Epicor's cost dimension model. We build a comprehensive account-to-dimension mapping matrix during discovery and validate it against the customer's top 50 transactions before committing to a full load. Skipping this step results in cost postings landing in generic suspense accounts rather than the correct operational cost centres.

  • Inter-company journals require decomposition and elimination entries

    Aqilla'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. 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 designed during scoping and validated against the group-level trial balance post-load. Migrations that skip this step end up with duplicate balances in the consolidated view.

  • Open journal periods must be coordinated before final cutover

    Aqilla enforces posting-date restrictions on open accounting periods. If transactions land in a period that is locked in Aqilla but not yet locked in Epicor, balances will disagree and the customer cannot reconcile. We coordinate a period-status checkpoint with the customer before the final cutover load, confirm both the Aqilla open-period list and the Epicor fiscal calendar, and carry forward any late adjustments as a post-migration journal batch. Epicor's fiscal period must be open before any journal import batch runs.

  • MTD submission history has no native Epicor equivalent

    Aqilla supports Making Tax Digital submission capability with automated UK VAT filing. Epicor ERP has no native MTD API integration. We migrate MTD submission history as an archive of submission records, but the customer must confirm any live MTD obligations with HMRC before cutover and document the third-party filing tool or manual process they will use post-migration. Failing to address this before go-live creates a compliance gap for UK organisations with active VAT filing obligations.

Migration approach

Six steps for a successful Aqilla to Epicor Prophet 21 data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

Aqilla logo

Aqilla

Source

Strengths

  • Cloud-native multi-entity architecture purpose-built for group finance consolidation.
  • Real-time published reporting with custom financial dashboards and analysis codes.
  • Automated FX processing and foreign exchange handling across subsidiaries.
  • Purchase-to-pay and order-to-cash workflows with built-in credit control and payment runs.
  • Making Tax Digital compliant for UK tax submissions with automated filing.

Weaknesses

  • Per-user seat pricing scales cost for large finance teams, particularly at Pro and Enterprise tiers.
  • Permission management lacks clarity — configuring access at granular object and area levels is error-prone.
  • API access requires an Enterprise add-on, limiting programmatic export options for smaller customers.
  • Customers report that some development requests and fine-tuning issues take extended time to resolve.
  • Reporting customisation, while powerful, requires a learning investment to use effectively.
Epicor Prophet 21 logo

Epicor Prophet 21

Destination

Strengths

  • Purpose-built for wholesale distribution with industry-specific replenishment, kitting, and counter-sale workflows out of the box.
  • Multi-warehouse management with bin locations, cross-docking, and real-time inventory visibility across all warehouse locations.
  • Automated replenishment engine with demand-based and min-max planning reduces stockouts and overstock carrying costs.
  • AI-infused reporting via Epicor Prism provides Gen AI-driven insights into ERP data without requiring a BI team.
  • Strong customer retention at 90% and a 50-year track record in the distribution vertical provides long-term vendor stability.

Weaknesses

  • High total cost of ownership — per-user pricing of $150-200/month plus $10K-$500K implementation creates significant budget commitment for small and mid-market distributors.
  • Customization via SDK requires technical expertise and introduces upgrade risk when custom code conflicts with new P21 releases.
  • Report generation performance is a known pain point — multiple users report system freezes during large or complex report exports.
  • Third-party bolt-on reliance for functionality that competitors include natively increases integration complexity and total solution cost.
  • Limited public API documentation — developers building custom integrations report difficulty finding P21 API authentication methods and endpoint specifications.

Complexity grading

How hard is this migration?

Standard ERP migration. 2 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Aqilla and Epicor Prophet 21.

  • Object compatibility

    B

    2 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Aqilla: Not publicly documented.

  • Data volume sensitivity

    B

    Aqilla doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Aqilla to Epicor Prophet 21 migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Aqilla to Epicor Prophet 21 data migrations

Answers to the questions buyers ask most during Aqilla to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most migrations land between four and eight weeks for single-entity organisations with under 5,000 GL transactions, no inter-company journals, and straightforward multi-currency settings. Multi-entity migrations with inter-company journal elimination, large invoice histories (over 20,000 lines), fixed-asset depreciation schedule carry-forwards, or complex analysis-code-to-cost-dimension mapping move to twelve to twenty-four weeks because of the schema design work, decomposition steps, and period-status coordination required.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Aqilla.
Land in Epicor Prophet 21, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day