Who this is for
IT managers, operations managers, and business owners running Pronto Xi who are facing upgrade decisions, support issues, or integration challenges.
Question this answers
What are our options for upgrading or modernising Pronto Xi, and what should we plan for?
What you'll leave with
- Common version and support issues affecting Pronto Xi users
- Upgrade paths and what each involves
- How to handle customisation and integration challenges during upgrades
- Key risks and decision points to consider
Platform overview
Pronto Xi is a mid-market ERP system popular with Australian manufacturers, distributors, and wholesale businesses. It covers financials, inventory, warehousing, manufacturing, and job costing. Pronto Software (now part of Aptean) develops and supports it.
What makes Pronto distinctive is the depth of customisation most implementations carry. Many Pronto environments have been running for 10-20+ years, accumulating layers of custom modules, bespoke reports, and integrations with everything from warehouse scanners to EDI systems.
That history is both the platform's strength (it's been moulded to fit your business) and its biggest upgrade challenge (all that custom code needs to survive the upgrade).
Common version & support issues
Version sprawl. Pronto Xi has gone through several major versions (700, 750, 760, 770). Each major release introduced significant architecture changes. If you're on 750 or earlier, the upgrade path to current versions is substantial.
End-of-support timelines. Older versions lose active support, meaning no more patches, security fixes, or vendor assistance. Running an unsupported version is a business risk — especially if you handle financial or customer data.
Custom module compatibility. Custom Pronto modules built using Progress 4GL or OpenEdge ABL may not compile or function correctly on newer versions. The more customisation you have, the more testing and re-engineering is needed.
Database and infrastructure ageing. Older Pronto installations often run on ageing Progress databases and on-premises servers that are themselves approaching end-of-life.
Upgrade and migration paths
In-place version upgrade. Upgrade from your current version to the latest supported release. This preserves your data and configuration but requires every customisation to be tested and potentially re-engineered. Typical timeline: 3-6 months.
Cloud migration. Move from on-premises to Pronto Cloud (hosted by Aptean) or a third-party hosting provider. Can be combined with a version upgrade or done separately. Moving to cloud doesn't change how Pronto works — it changes where it runs.
Parallel replacement. If your Pronto environment is heavily customised and the upgrade cost is approaching the cost of a replacement, it may make sense to evaluate alternative platforms. This isn't common, but it's worth considering if upgrade costs exceed 60-70% of replacement costs.
Staged modernisation. Keep Pronto for what it does well (financials, inventory, core ERP) and build modern web applications around it for areas where Pronto struggles (customer portals, mobile access, advanced reporting, API-first integrations).
Customisation & integration challenges
Custom module audit. The first step in any Pronto upgrade is auditing every customisation. Categorise each one: still needed, can be replaced with standard functionality, needs re-engineering, can be retired.
Progress/OpenEdge code. Custom code written in Progress 4GL or OpenEdge ABL needs testing against the target version. Syntax changes, deprecated features, and API changes can break existing code.
Integration points. Most Pronto environments have integrations built at different times using different methods — flat files, direct database connections, custom APIs, scheduled imports. Each one needs mapping and testing during the upgrade.
- Flat file integrations are the most fragile — they break if field positions or formats change
- Direct database connections from external systems may fail if table structures change
- Custom APIs need version compatibility testing
- EDI integrations require particular attention as field mapping changes can disrupt supply chain operations
Reporting. Custom reports built in Progress reporting tools or Business Intelligence layers may need updating. Crystal Reports, SSRS, or Power BI connections all need testing against the new version's data structures.
Risks and decision points
Key risks to assess
- Customisation volume
More than 30 custom modules means a complex upgrade. Get a full audit before committing.
- Integration fragility
Flat file and database-direct integrations are high risk. Plan to modernise these during the upgrade.
- Version gap
More than 2 major versions behind means more breaking changes to address.
- Staff availability
You'll need key users for UAT. Plan for their time during the testing phase.
- Business continuity
Plan your upgrade around quiet periods. Don't schedule go-live during peak season.
Decision points
- Upgrade or modernise around?
If the core ERP functionality is sound, upgrade. If the pain is in areas Pronto doesn't cover well, build around it.
- Cloud or on-premises?
Evaluate this separately from the version upgrade. Cloud reduces infrastructure burden but adds hosting costs.
- Re-engineer or retire customisations?
Don't automatically carry every customisation forward. Some may no longer be needed.
- Big bang or staged?
For complex environments, a staged approach reduces risk but extends the timeline.
How HELLO PEOPLE can help
We don't replace your Pronto partner. We handle the custom software, integrations, and automation that sits around your ERP — the parts that often cause the most pain during upgrades.
- Customisation audit: We review your custom modules, integrations, and reports and classify them by upgrade risk
- Integration modernisation: Replace fragile flat-file and database-direct integrations with modern API connections
- Custom application development: Build web-based tools for functions that Pronto handles poorly (customer portals, mobile apps, dashboards)
- Data migration support: Extract, transform, and validate data during version upgrades or platform migrations
- Reporting modernisation: Move from legacy reporting tools to modern dashboards (Power BI, custom dashboards)
Frequently asked questions
How long does a Pronto Xi version upgrade typically take?
A major version upgrade typically takes 3-6 months including planning, testing customisations, data migration, and user training. Smaller point releases are faster but still need proper testing, especially if you have custom modules.
Can we keep our existing customisations when upgrading Pronto Xi?
It depends on the customisation method. Well-structured customisations built through supported extension points usually carry forward. Deep modifications to core code often break during upgrades and need re-engineering. A customisation audit before upgrading will identify which ones are at risk.
Should we move Pronto Xi to the cloud?
Cloud hosting can reduce infrastructure overhead and improve remote access, but it's not automatically the right choice. Consider your data residency requirements, integration landscape, and whether your customisations work in a hosted environment. We can assess your setup and give you a clear recommendation.
What happens if we don't upgrade and stay on our current version?
You'll miss out on security patches, new features, and eventually vendor support. Over time, finding developers who know your specific version gets harder. The longer you wait, the more expensive the eventual upgrade becomes because the gap between versions grows.
Can HELLO PEOPLE support Pronto Xi or do we need a Pronto partner?
We don't replace your Pronto partner for core ERP work. We help with the custom software, integrations, reporting, and automation that sits around Pronto — the parts that often cause the most pain during upgrades.
Key takeaways
- Pronto Xi upgrades are manageable with proper planning — the customisation audit is the most critical first step
- Cloud migration and version upgrades are separate decisions — don't conflate them
- Legacy integrations (flat files, scheduled imports) are often the biggest risk during an upgrade
- If you're more than two major versions behind, expect a more complex migration project
- Budget for customisation re-engineering — most Pronto environments have significant custom code