Where ABRA Starts Holding Companies Back
ABRA works well within its original scope: accounting, basic stock management, invoicing. That scope was designed for smaller businesses a decade ago. As companies scale, a few recurring problems start appearing.
- Reporting requires Excel exports: Business intelligence in ABRA means exporting data and building reports manually. Real-time dashboards, multi-dimensional analysis, or anything close to a live overview is not in the product.
- No real CRM layer: ABRA tracks customers as accounting entities, not as relationships. There is no pipeline, no activity logging, no automated follow-ups. Sales teams end up managing leads in spreadsheets alongside ABRA, which creates two sources of truth and neither is reliable.
- Integrations are fragile: Connecting ABRA to an e-shop, a marketplace, or a logistics system involves either Stormware's middleware or expensive custom XML connectors. They break when the other system updates. Maintenance is constant.
- Mobile access is an afterthought: Field staff, warehouse workers, and managers who need to approve a document off-site run into real limitations. ABRA's mobile story has not kept pace with how businesses actually operate.
- Multi-entity and multi-currency complexity: Companies expanding across borders or managing multiple legal entities find ABRA increasingly awkward. Consolidation is a manual exercise.
None of this means ABRA is a bad system. It means ABRA was built for a specific moment in a company's growth, and some companies have grown past it.
What We Actually Migrate (and What We Don't)
One of the first conversations we have with clients is about data scope. Not everything in ABRA is worth migrating. Moving dirty or irrelevant historical data into a clean new system is one of the fastest ways to make the new system feel like the old one.
What we typically migrate:
- Active customers and suppliers: including contacts, payment terms, and credit limits
- Product catalogue: items, units, prices, supplier relationships
- Current inventory: stock levels, locations, lot and serial numbers where applicable
- Open transactions: sales orders, purchase orders, open invoices
- Accounting opening balances: receivables, payables, and the general ledger opening position
What we usually leave behind:
- Historical transactions older than 2-3 years: these are archived in ABRA and remain accessible for accounting/tax purposes without living in the new system
- Closed orders and invoices: unless there is a specific regulatory or analytical reason to carry them forward
- Legacy custom reports: these get rebuilt in the new platform where the architecture actually supports them
The data audit is the first deliverable of any migration project. It defines exactly what moves, what stays, and what gets cleaned up before the move.
ABRA Data Migration: The Technical Reality
ABRA exports data via XML (the Pohoda/ABRA XML format) and CSV. The XML export is comprehensive but requires transformation work: field mapping, encoding cleanup, deduplication, and validation against the target system's data model.
Three things make ABRA migrations more complex than simpler systems:
- Customizations: Many ABRA installations have been customized over years , additional fields, modified workflows, company-specific document templates. These do not export cleanly and need manual mapping decisions.
- Accounting history structure: ABRA's chart of accounts and cost centre setup is often company-specific. Mapping this to a new chart of accounts is accounting work, not just technical work. We always involve the client's accountant in this step.
- Master data quality: After 10 years in any system, customer records accumulate duplicates, outdated contacts, and inconsistent coding. We run a data cleansing pass before migration, not after.
We use a combination of automated scripts and manual validation to handle the transformation. The migration runs against a staging environment first, so the client can verify data integrity before anything touches production.
The Migration Process: 5 Phases
Phase 1: Discovery and Scoping (2–3 weeks)
We map the current ABRA setup, business processes, and integration dependencies. Every customization gets documented. The output is a fixed scope, a migration plan, and a budget. No project starts without a signed scope document.
Phase 2: Data Audit and Cleansing (1–2 weeks)
We export the ABRA data and run an audit: volume, quality, completeness, duplicates. The client reviews the audit and makes decisions about what migrates. Cleansing happens here, before anything is moved.
Phase 3: System Build and Data Migration to Staging (3–6 weeks)
We configure the new system to match the agreed scope and migrate all data to a staging environment. The client's key users access the staging instance and run through their daily workflows. This is UAT , user acceptance testing , and it typically produces a punch list of adjustments.
Phase 4: Parallel Run (1–2 weeks)
For a defined period, both systems run simultaneously. New transactions are entered in the new system; ABRA is kept as a fallback. This de-risks the cutover and gives the team confidence before the old system is switched off.
Phase 5: Go-Live and Hypercare (2–4 weeks post-launch)
Cutover happens on a planned date, typically a month-end or quarter-end for accounting cleanliness. We provide intensive support for the first weeks after go-live , response time measured in hours, not days.
Timeline and Investment
Total project duration ranges from 8 to 20 weeks depending on company size, number of users, and integration complexity. Cost estimates for Czech market in 2026:
| Company size | Users | Typical duration | Implementation cost |
|---|---|---|---|
| Small | 5–15 | 8–10 weeks | 150,000–300,000 Kč |
| Mid-size | 15–40 | 12–16 weeks | 400,000–900,000 Kč |
| Larger | 40–100 | 16–20 weeks | 900,000–2,500,000 Kč |
These figures cover scoping, project management, configuration, data migration, testing, training, and post-launch support. Platform licensing is separate and depends on the system chosen.
The single biggest variable in cost is customization. Companies that have heavily customized ABRA over the years carry that complexity into the migration. We always surface this in the discovery phase so there are no surprises later.
The Most Common Risks , and How We Handle Them
- Data quality problems discovered mid-project: We front-load the data audit to find these early. If significant cleaning is needed, it extends the timeline before it extends the budget.
- Scope creep: Every migration surfaces "while we're at it" requests. We log these as change requests with separate pricing rather than absorbing them into the original scope. This keeps the original project on track.
- User resistance: People who have used ABRA for years know it well. The new system is unfamiliar. We schedule training sessions early and involve key users in UAT so they feel ownership over the result rather than having it imposed on them.
- Accounting period alignment: Migrating mid-year creates reconciliation headaches. We plan cutover dates with the client's accountant from the start.
