ERP Implementation in 90 Days: Roadmap and Common Mistakes

An ERP implementation in 90 days is realistic for mid-size companies (30–100 employees, 1–3 entities) adopting a well-designed cloud ERP. More than 90 days usually signals scope creep, slow decision-making, or excessive customization. This article presents the proven roadmap and the 7 mistakes that most often derail ERP projects.

Note: this plan assumes a modern cloud ERP with native integrations for Panama (PAC, IFRS, payroll). Traditional on-premise typically requires 6–18 months.

The 90-day roadmap

Four phases that partially overlap:

Phase	Days	Objective
1. Discovery	1–21	Understand the current state and design the target state
2. Configuration	15–50	Configure the ERP and migrate data
3. Parallel run	45–75	Validate the ERP while operating alongside the old system
4. Go-live	75–90	Final cutover and intensive support

Phase 1: Discovery (days 1–21)

Objective: alignment. Without this, the project goes off the rails.

Activities

Kick-off: project team identified (sponsor, project lead, lead accountant, IT, key users).
Current state map: what systems you use today, what processes, what critical reports.
Target state definition: what the new ERP must do, what reports are non-negotiable.
Scope definition: what IS being implemented in this project, what is NOT (phase 2).
Signed schedule from all stakeholders.
Measurable success criteria (close time, accuracy, access, etc.).

Deliverable

A signed project scope document: clear pages on what will be done, what will not, timelines, team, and acceptance criteria.

Typical discovery mistakes

Skipping discovery to jump straight into configuration.
Not involving the executive sponsor in decisions.
Superficial discovery that does not capture real operational exceptions.
Verbal commitments without documentation.

Phase 2: Configuration and data migration (days 15–50)

Objective: have the ERP configured and data loaded, ready for the operational team to test.

ERP configuration

Chart of accounts per applicable IFRS (SME or Full IFRS).
Master records: customers, suppliers, products, cost centers.
Tax types: ITBMS at 7%, 10%, 15%, and withholdings.
Document numbering: invoices, receipts, credit notes.
PAC integration for electronic invoicing.
Payroll configuration: CSS, Income Tax (ISR), 13th month, seniority premium.
Multi-company if applicable.
User roles and permissions.

Data migration

Opening balances: balance at the end of the last month.
Master data: customers, suppliers, products.
Accounts receivable and payable: outstanding invoices with detail.
Inventory: quantities in warehouse and unit cost (if applicable).
Bank balances.

Recommendation: do NOT migrate the complete historical transaction log. Migrate opening balances and keep the old system as a queryable historical archive. This significantly reduces the project scope.

Technical testing

PAC sandbox: issue test invoices with CUFE.
Reports: validate that critical reports are generated correctly.
Performance: validate response times under real volumes.
Security: validate that roles work as designed.

Phase 3: Parallel run (days 45–75)

Objective: the team operates both systems (old + new) simultaneously for 3–4 weeks, validating that the new ERP produces the same results as the old one.

Parallel run structure

Old system is the source of truth: operational decisions are made with its data.
New ERP is the test: every transaction is also recorded there.
Weekly reconciliation: does the new ERP produce the same balances as the old one?
Gap list: every difference is documented and resolved.

Training during the parallel run

Accounting: transaction recording, period close, reports.
Invoicing: issuance with PAC, credit notes.
Inventory: receipts, issues, transfers.
Purchasing: invoices, payments, withholdings.
Reports: how to obtain each critical report.

Parallel run risks

Double workload: the team records everything twice. It is exhausting. Keep the parallel run as short as is sufficient to validate.
Resistance: users prefer the old system. Without active leadership, they "forget" to enter data in the new one.
Inevitable differences: rounding, different configurations. Document and decide which are acceptable.

Phase 4: Go-live and support (days 75–90)

Objective: final cutover from the old system and normal operations in the new ERP.

Cutover day

Last transaction in the old system: Friday at close of business.
Final financial statements from the old system.
Opening balance adjustment in the new ERP if anything changed since the parallel cutover.
Full backup of the old system (legal historical archive).
Monday: 100% operations in the new ERP.

First 2 weeks

Intensive support: response < 1 hour for operational questions.
Daily stand-up of the project team.
Fast incident resolution.
Fine-tuning of configuration as issues are identified.

Next 4 weeks

First monthly close in the new ERP.
Reconciliation with the old system (the prior month's close must match).
Report adjustments based on feedback.
Final process documentation.

Stabilization (days 60–90 post-go-live)

Standard support without daily stand-up.
Minor issues resolved via tickets.
Phase 2 plan for features excluded from this project.

The 7 mistakes that derail implementations

Symptom: "the CFO is busy," "the owner doesn't have time."

Consequence: when difficult decisions arise (scope, budget, escalation), nobody makes them. The project stalls.

Mitigation: designate an executive sponsor from day 1. Monthly follow-up meetings at minimum.

Mistake 2: Superficial discovery

Symptom: "we already know what we do, let's go straight to the ERP."

Consequence: requirements surface during configuration. Rework.

Mitigation: invest 2–3 weeks in serious discovery. Document real operational exceptions (not just the happy path).

Mistake 3: Scope creep

Symptom: "while we're at it, let's add feature X."

Consequence: the project grows, deadlines slip, budget overruns.

Mitigation: maintain a formal change request log; items that are approved go to phase 2 (post-go-live).

Mistake 4: Migrating the full historical transaction log

Symptom: "we need the last 5 years of transactions in the ERP."

Consequence: multiplied complexity with no real value. One extra month added to the project.

Mitigation: opening balances only, keep the old system as a queryable archive.

Mistake 5: Excessive customization

Symptom: "the ERP must look exactly like our current system."

Consequence: implementation cost doubles or triples. Future updates become problematic.

Mitigation: standard configuration first. Only customize what is truly critical to the business.

Mistake 6: Insufficient training

Symptom: "the system is intuitive, users will learn by doing."

Consequence: the team operates the system incorrectly, generates errors, gets frustrated, reverts to old habits.

Mitigation: formal role-based training + supervised practice during the parallel run + process documentation.

Mistake 7: Cutting over without a parallel run

Symptom: "let's do a direct cutover, we'll save 3 weeks."

Consequence: chaos at close, incorrect reports, loss of credibility in the system with the team. Takes months to stabilize.

Mitigation: 3–4 week parallel run minimum, non-negotiable.

Project team

Role	Dedication	Responsibility
Executive sponsor	5–10%	Critical decisions, escalation
Internal project lead	60–80%	Day-to-day coordination
Lead accountant	50–70%	Accounting configuration, validation
Operations lead	30–50%	Operational processes, validation
IT	20–40%	Integrations, access, infrastructure
Key users (3–5 people)	30–40%	Testing, parallel run, training

Without this level of dedication, the project will extend beyond 90 days.

How cifraHQ accelerates implementations

cifraHQ has pre-built templates and methodology:

Discovery with Panamanian templates: IFRS, DGI, CSS, ITBMS pre-configured.
Native importers from QuickBooks, Sage 50, Excel.
Pre-integrated PAC: WebPOS, Alanube, The Factory HKA.
Pre-configured IFRS chart of accounts.
Local implementation team that knows Panamanian operational realities.
60-day post-go-live support included.

Ready for your implementation? Request a demo or read our guide to migrating from QuickBooks first.

Every implementation is different. This roadmap presents a typical scenario; your plan must be adjusted to your operational reality.