ERP migration
Field-level mapping, validation, and rollback between ABRA Gen and Infor CloudSuite Corporate. We move data and schema; workflows are rebuilt natively in Infor CloudSuite Corporate.
ABRA Gen
Source
Infor CloudSuite Corporate
Destination
Compatibility
11 of 12
objects map 1:1 between ABRA Gen and Infor CloudSuite Corporate.
Complexity
BStandard
Timeline
6-10 weeks
Overview
Moving from ABRA Gen to Infor CloudSuite is a cross-platform ERP migration requiring direct database extraction from ABRA Gen's on-premise SQL or proprietary store, followed by transformation and load via Infor's Migration Utility into a CloudSuite migration database. There is no REST API for ABRA Gen, so every migration begins with a database audit to map the live schema against the standard ABRA Gen data dictionary and identify any custom extensions. Czech accounting records require a chart-of-accounts restructure because ABRA Gen's COA follows Czech statutory account classes while Infor CloudSuite uses its own industry-specific account structure. We preserve closed fiscal-year records as read-only archives for the mandatory Czech and Slovak 5-to-10-year retention window rather than loading them into the operational CloudSuite database. Custom modules and custom firmy extensions require manual schema comparison and field-by-field mapping, flagged for customer review before load. We do not migrate ABRA Gen workflows, custom reports, or desktop-client configurations; these require rebuild in Infor OS, Birst, or Mongoose depending on the artifact type, and we deliver a written inventory for the customer's implementation team.
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.
Source platform
ABRA Gen platform overview
Scorecard, SWOT, gotchas, and pricing for ABRA Gen.
Destination platform
Infor CloudSuite Corporate platform overview
Scorecard, SWOT, gotchas, and pricing for Infor CloudSuite Corporate.
Data migration guide
The complete Infor CloudSuite migration guide
Data model, import mechanisms, field mapping strategy, pitfalls, and cutover — by the engineers running it.
Destination checklist
Infor CloudSuite migration checklist
Pre- and post-cutover tasks for moving onto Infor CloudSuite Corporate.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a ABRA Gen object lands in Infor CloudSuite Corporate, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
ABRA Gen
Firmy (Companies/Accounts)
Infor CloudSuite Corporate
Account + Address
1:1ABRA Gen firmy records contain address, contact, financial classification, and sometimes custom fields. We map firmy to Infor CloudSuite Account with associated Address records. The firmy ICO (company registration number) maps to a custom field on Account to preserve the Czech business identifier. Custom firmy extensions identified during database audit require manual field-level mapping to Infor Account extension fields or custom fields on Account.
ABRA Gen
Dodavatele (Vendors)
Infor CloudSuite Corporate
Supplier + Address
1:1ABRA Gen dodavatele records include payment terms, banking details, and vendor-specific discount structures. We map dodavatele to Infor CloudSuite Supplier records with associated Address entries. Payment terms from ABRA Gen (e.g., specific Czech payment day conventions) map to Infor's Payment Terms configuration table. Vendor-specific discount structures become custom fields on Supplier.
ABRA Gen
Odberatele (Customers)
Infor CloudSuite Corporate
Customer + Address
1:1ABRA Gen odberatele records mirror the vendor structure with billing and shipping details. We map odberatele to Infor CloudSuite Customer records, preserving the original ABRA Gen customer code as a reference field. In scenarios where ABRA Gen uses the same firmy record for both company and customer relationships, we split into separate Infor Account and Customer records based on the record type flag.
ABRA Gen
Zakazky (Jobs/Contracts)
Infor CloudSuite Corporate
Project / Work Order
1:1ABRA Gen zakazky capture project-level financial tracking, billing, and cost allocation. We map zakazky to Infor CloudSuite Project or Work Order depending on the customer's operational use. Job codes preserve as Project codes. Nested zakazky hierarchies require flattening into a Work Breakdown Structure in Infor Project. Job-specific cost centers map to Infor Cost Codes.
ABRA Gen
Vyrobky (Products/Items)
Infor CloudSuite Corporate
Item Master (Product2 equivalent)
1:1ABRA Gen vyrobky records include pricing, BOM, unit-of-measure definitions, and product variants. We map vyrobky to Infor CloudSuite Item Master. Multi-level BOMs in ABRA Gen require flattening or reconstruction in Infor's BOM management because Infor CloudSuite Industrial represents BOM structures differently with routing and work center assignments. Unit-of-measure definitions map to Infor's UoM conversion tables.
ABRA Gen
Sklady (Warehouses/Stock)
Infor CloudSuite Corporate
Warehouse + Bin/Location
1:1ABRA Gen sklady records cover stock locations, quantities, and inventory valuation methods. We map warehouse codes to Infor CloudSuite Warehouse records with corresponding Bin/Location structures. Serialized and lot-controlled items from ABRA Gen require mapping to Infor's lot/serial number tracking. Inventory valuation method differences (e.g., Czech-specific cost methods) map to Infor's inventory valuation configuration, with any unsupported methods flagged for customer finance review.
ABRA Gen
Ucetni (Accounting Records)
Infor CloudSuite Corporate
General Ledger + Journal Entry
1:1ABRA Gen ucetni records represent Czech accounting journal entries with COA structures and tax codes tied to Czech statutory requirements. We map account codes to Infor CloudSuite's General Ledger chart of accounts, performing a structural COA mapping that translates Czech account class numbers (1-9) to the Infor account structure. Document-level detail and audit trails preserve for each journal entry. Closed fiscal years migrate as read-only historical records; open fiscal years load into Infor's open GL.
ABRA Gen
Doklady (Documents/Invoices)
Infor CloudSuite Corporate
AP/AR Voucher + Invoice
1:1ABRA Gen doklady records include sales invoices, purchase orders, and delivery notes as document headers with line items. Open invoices (unpaid AP/AR) map to Infor CloudSuite vouchers and invoice records. Historical closed invoices migrate as read-only reference records if the retention scope covers them. Posting dates outside the migration window are flagged and excluded from operational load into Infor's live AP/AR tables.
ABRA Gen
Zamestnanci (Employees)
Infor CloudSuite Corporate
Employee
1:1ABRA Gen zamestnanci records include employment status, department assignment, and contact data. We map to Infor CloudSuite Employee records. Czech/Slovak employee data privacy requirements (GDPR compliance) are respected during extraction; national ID numbers and sensitive fields are mapped to the corresponding Infor Employee fields with access controls configured per the customer's data residency requirements.
ABRA Gen
Uzivatele (Users)
Infor CloudSuite Corporate
User
1:1ABRA Gen uzivatele records contain user accounts, roles, and permission sets. We map user records to Infor CloudSuite User accounts, resolving role and permission structures to Infor's role-based access model. Inactive ABRA Gen user accounts are flagged to be deactivated at cutover. The mapping preserves the original ABRA Gen user login name as a reference field for audit trails.
ABRA Gen
Custom Modules / Tables
Infor CloudSuite Corporate
Custom Objects / Extension Fields
1:1Custom-developed ABRA Gen modules and heavily customized standard modules identified during the database audit require manual schema comparison. We inspect the live database schema against the standard ABRA Gen data dictionary to identify custom tables and extended columns. Each custom object is mapped manually to Infor custom objects or extension fields on standard Infor objects, and flagged for customer review before load. Custom module behavior logic does not migrate; it requires rebuild by the customer's Infor implementation partner.
ABRA Gen
Fiskální Období (Fiscal Periods / Closed Years)
Infor CloudSuite Corporate
GL Period Archive
lossyCzech and Slovak tax law mandates retention of accounting records for 5 to 10 years depending on document type. We do not load closed fiscal years into Infor CloudSuite's operational GL; instead, we export them as read-only archive files in a structured format (CSV or XML) alongside the migration. The archive satisfies legal retention requirements without bloating the Infor operational database. The customer's finance team retains access to the archive for statutory audit requests.
| ABRA Gen | Infor CloudSuite Corporate | Compatibility | |
|---|---|---|---|
| Firmy (Companies/Accounts) | Account + Address1:1 | Mapping required | |
| Dodavatele (Vendors) | Supplier + Address1:1 | Mapping required | |
| Odberatele (Customers) | Customer + Address1:1 | Mapping required | |
| Zakazky (Jobs/Contracts) | Project / Work Order1:1 | Mapping required | |
| Vyrobky (Products/Items) | Item Master (Product2 equivalent)1:1 | Mapping required | |
| Sklady (Warehouses/Stock) | Warehouse + Bin/Location1:1 | Mapping required | |
| Ucetni (Accounting Records) | General Ledger + Journal Entry1:1 | Mapping required | |
| Doklady (Documents/Invoices) | AP/AR Voucher + Invoice1:1 | Mapping required | |
| Zamestnanci (Employees) | Employee1:1 | Mapping required | |
| Uzivatele (Users) | User1:1 | Mapping required | |
| Custom Modules / Tables | Custom Objects / Extension Fields1:1 | Fully supported | |
| Fiskální Období (Fiscal Periods / Closed Years) | GL Period Archivelossy | Fully supported |
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.
ABRA Gen gotchas
On-premise deployment requires direct database access
Custom modules and extensions lack standard documentation
Historical accounting data retention obligations vary by jurisdiction
No publicly documented REST API for ABRA Gen
Infor CloudSuite Corporate gotchas
Infor OS tier-based usage limits gate API and BaaS capabilities
Custom Fields use inconsistent naming across Infor editions
SQL migration utility requires source database access
Multi-site and multi-currency data require separate period closure sequencing
REST API payload and timeout limits restrict bulk migration throughput
Pair-specific challenges
Migration approach
Database access and discovery audit
We coordinate with the customer's IT team to obtain read-only access to the ABRA Gen production database. We run a discovery audit that extracts the live schema, compares it against the standard ABRA Gen data dictionary, identifies custom tables and extended fields, catalogs active modules, and estimates record counts per object. The audit output is a written migration scope document listing every object to be migrated, the record count per object, the active historical periods in ucetni and doklady, and a preliminary COA mapping table. This step establishes whether the ABRA Gen database uses SQL Server (compatible with Infor Migration Utility) or a proprietary format requiring export to SQL Server first.
Infor CloudSuite schema design and COA mapping
We work with the customer's Infor implementation team to design the target schema in Infor CloudSuite. This includes provisioning Item Masters, Account structures, Warehouse and Bin configurations, Supplier and Customer records, and Project/Work Order templates. The Czech COA restructure maps ABRA Gen account codes to Infor GL account ranges. We resolve any unit-of-measure and tax-code gaps between ABRA Gen and Infor configurations before data extraction begins. Custom fields in Infor CloudSuite are created to receive any ABRA Gen custom data that does not map to standard Infor fields.
Historical data scope and archive strategy
We confirm with the customer which historical periods must be preserved and in what form per Czech and Slovak tax retention law. We recommend a split strategy: open fiscal year and recent 1-2 years of closed records load into Infor CloudSuite operational tables; older closed fiscal years export as read-only archive files. We also recommend posting all unpaid invoices, vouchers, and journals in ABRA Gen before extraction begins so that Infor CloudSuite receives the most accurate open-position data at cutover.
Test migration and reconciliation
We run a full test migration into an Infor CloudSuite staging or sandbox environment using production-like data volumes. The customer's finance and operations leads reconcile record counts (Accounts in, Suppliers in, Items in, Projects in, GL entries in), spot-check field-level mappings for 25-50 records per object against the ABRA Gen source, and validate COA mapping by running a trial balance comparison. Any mapping corrections, data quality issues, or custom object gaps identified during reconciliation are resolved before the production migration window opens.
Production migration in dependency order
We run production migration following Infor's sequence-ordered dependency model: prerequisite codes (UoM, tax codes, warehouse codes) load first, followed by master data (Suppliers, Customers, Item Masters, Accounts), then transactional data (Projects, open Orders, open AP/AR vouchers), and finally GL journal entries. Czech and Slovak account codes resolve to Infor GL accounts during transform. Any BOM flattening or account restructure happens in the transform layer. Each phase emits a row-count reconciliation report before the next phase begins. Open ABRA Gen transactions that arise during the migration window are held and migrated in a delta pass at cutover.
Cutover, validation, and custom module handoff
We freeze ABRA Gen writes during the cutover window, run the final delta migration, then enable Infor CloudSuite as the system of record. We deliver the ABRA Gen custom module inventory document to the customer's Infor implementation partner for rebuild in Mongoose or Birst. We do not rebuild ABRA Gen custom reports or desktop-client workflows in Infor CloudSuite as standard scope. We support a one-week hypercare window to resolve any reconciliation discrepancies raised by the customer's team during the first production week.
Platform deep dives
ABRA Gen
Source
Strengths
Weaknesses
Infor CloudSuite Corporate
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 1 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 ABRA Gen and Infor CloudSuite Corporate.
Object compatibility
1 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
ABRA Gen: Not publicly documented.
Data volume sensitivity
ABRA Gen 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 ABRA Gen to Infor CloudSuite Corporate migration scoping. Not seeing yours? Book a call.
Walk through your ABRA Gen to Infor CloudSuite Corporate migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave ABRA Gen
Other ways to arrive at Infor CloudSuite Corporate
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.