Fast Tracking Economic Advantage from Core Solution Upgrades

Methodology

This study involved 23 in-depth case studies and interviews with Australian organisations that had undertaken core solution upgrades or migrations between 2018 and 2025. Organisations were selected from a range of industries and were mid-sized to large enterprises. Public sector and organisations involved in critical infrastructure and public-facing services (such as local government, education, health, etc.) were prioritised for this report, given the complexities of their core solutions. Case studies, included ‘counter-factual’ cases to counter the most common deployment approaches (migrations to software-as-a-service) and ensure that other variables impacting time to value were explored.

All information was gathered under Chatham House Rule and anonymised before analysis. All case studies are presented in an anonymised form to enable replication of the analysis.

Artificial intelligence tools were used to help identify correlations between the case study transcripts (similarity analysis). Senior IBRS researchers conducted the analysis and write-ups.

This study was funded by TechnologyOne. In keeping with IBRS’ vendor independence policies, TechnologyOne did not shape the interviews, nor bias the analysis. Several TechnologyOne clients were interviewed as case studies, with a larger number coming from IBRS’ own database and peer network.

IBRS thanks TechnologyOne for their patronage and for supporting local, independent research.

Dr. Joseph Sweeney

Research Director
IBRS

Why consider a core solution refresh now?

“While AI may be getting the headlines, the number one ICT challenge facing Australian organisations, based on actual inquiries and research data collected by IBRS, is core solution upgrades. The upswing in core business solution upgrades is due to many critical and long-overdue upgrades being put on hold during COVID-19, as organisations pivoted to hybrid working and reimagined their workplace environments. Many organisations now find themselves with outdated, legacy core solutions that have reached end-of-life support. Add to this the push towards SaaS, and ICT leaders are facing the perfect storm when it comes to core solutions.”

Dr Joseph Sweeney,
Research Director
Advisor, Future of Work, IBRS

Executive Summary

Rethinking Conventional Wisdom

What the Data Shows Us: IBRS analysis reveals a counter-intuitive correlation: projects with heavy reliance on tier 1 consulting firms for strategy and management were statistically more likely to experience budget overruns and extended timelines. Conversely, projects led by strong internal teams, supported by vendors and niche tier 2 consultancies, correlated strongly with shorter delivery times and adherence to budget.

Why This Occurs: The disparity stems from a misalignment of methodologies. tier 1 firms often rely on established, heavy-weight frameworks and ‘build and run’ models that clash with the agility required for modern SaaS implementations. Furthermore, when strategy is outsourced, organisations often lack the internal ownership necessary to drive business process changes.

In contrast, internal teams possess the contextual knowledge to prioritise features effectively, whilst vendors possess the deep product knowledge to configure the software rapidly.

Recommendations: The Ideal Resource Mix – The data suggests that the ‘outsourced’ model is obsolete for core SaaS upgrades. The optimal structure requires the client organisation to retain control of the ‘what’ and ‘why’, whilst leveraging partners for the ‘how’.

• Internal Team (The Lead): Must retain control of strategy, project management, and change management. Success hinges on a dedicated internal Executive Sponsor and business staff who drive requirements and user adoption.
• The Vendor (The Technical Core): Best utilised for configuration, feature mapping, and data migration. They should be leveraged to map product capabilities to business needs and handle the ‘heavy lifting’ of technical setup.
• Tier 2 Consultancies (The Specialists): Ideal for tactical resource augmentation. Use these firms for specific, isolated tasks such as integration development, complex API work, or custom workflow construction.
• Tier 1 Consultancies (The Exception): Should be reserved only for highly complex, custom re-implementations or managed via ‘shared risk’ contracts (e. g., escrow models) that financially incentivise speed and efficiency.

Top Ten Facts Impacting Time to Value

Structure

Fact 1. In-House vs. Consulting

The balance between in-house teams and external consultants impacts the speed of the upgrade. The optimal mix of resources is an in-house team consisting of project managers and a pool of line-of-business leaders who guide the project, a highly specialised consultancy, or in some cases several smaller consultancies working in tandem, with clearly defined discrete tasks and roles. The specialised partners perform niche tasks related to legacy migration and integration with the rest of the client’s ecosystem, and are supported by consultancy services from the vendor for guidance and configuration support.

“Relying heavily on tier 1 consultants introduces delays for two reasons: there is little or no imperative to minimise effort and reduce time to value for the client because of their time and material pricing model, and it introduces coordination challenges. In contrast, a strong in-house team leading the effort expedites the process.”

Fact 2. Shared Responsibility: Resource Availability

The availability of skilled personnel, both internal and external, can affect the speed of the upgrade. Organisations with limited resources struggled to meet project timelines.

“Handing over projects to a tier 1 contractor or consulting firms did not improve the time to delivery and increased overall costs.”

Instead, this study found that organisations with limited internal resources were best served by focusing on project management, with internal project and change management leads working closely with business stakeholders and project leads, and breaking up implementation into several specialised external partners, including the vendor.

For example, a new platform would be defined by internal leads but configured by the vendor, with data cleaning and migration conducted by an external specialist, custom integrations developed by another specialist, security audits and refinement conducted by a third, and some training and change management conducted by a separate specialist.

Fact 3. Vendor Support and Involvement

The level of support from the product vendor, such as SAP’s Max Attention program and TechnologyOne’s SaaS Plus, influences the timeline of the upgrade process. Enhanced vendor support in specific areas, specifically data migration and configuration, streamlines governance and quality assurance, thereby reducing the time required for upgrades. However, this needs to be balanced with internal project management capabilities (see Fact 1).

Fact 4. Change Management and User Training

Effective change management strategies and user training programs are essential for a smooth transition. Poorly managed change can lead to resistance from users, which can delay the adoption of the new system.

“Knowing which areas of the new platform to focus on for change management and training was a significant factor in the speed at which a new system could be deployed.”

Organisations that engaged business units early to determine specific business processes and tasks were priority targets for training and change management, as well as for prioritising enabling features in the SaaS platform. They had both lower overall costs for the change management program and faster transition times.

The role of vendors in training on priority technical areas was said to save time, primarily when conducted in line with vendor support in data migration and configuration. User training appears to be more effective when conducted by internal teams, with the vendor providing support in the form of ‘train the trainer’ services and collateral.

Project Management and Governance

Fact 5. Project Management Methodologies

The choice of project management methodologies (e. g., agile vs. waterfall) significantly impacts the upgrade timeline. Agile methodologies that allow for iterative testing and feedback can lead to faster adjustments and a more responsive upgrade process. However, waterfall methods also have their place.

This study suggests that different methodologies should be employed at various stages of the core solution refresh. For example, during early stages of evaluating needs with stakeholder engagement through to product selection, and during development of integrations and configuration of new modules, agile methods work well. Implementation and migration of data work better with waterfall approaches. The key determining factor in the selection of methodology is ‘type of risk’ being managed. During phases where the risk is largely related to unknowns (product capabilities, new organisational opportunities, possible benefits mapping, rapid prototyping of new digital processes, etc.) agile is more appropriate. Where the risk is largely process, time and resource considerations and there are few ‘unknowns’ (implementation, data migration, etc.) waterfall is more appropriate.

In addition, the architecture and level of customisation impact which project methods are ideal. For example, upgrades or cross-grades of modern SaaS solutions favour agile methodologies, while migrating from a legacy on-premises solution to an entirely new SaaS solution tends towards waterfall in the early stages and planning, with agile for execution.

Fact 6. Testing and Quality Assurance

The thoroughness of testing, including automated regression testing, is crucial. Organisations that invest in robust testing frameworks can identify issues early, reducing the time spent on post-upgrade fixes. However, when mitigating modern platforms, testing is best viewed through a risk-driven lens, where the focus is on features that most impact the organisation if they were to malfunction, while less impactful issues are given less attention. This reduces the testing time and thus costs.

Architecture and Technology Considerations

It has been recognised for more than two decades that the architectural complexity, especially the level of customisation, of aged systems dramatically impacts the time and costs of upgrades or migrations. However, from the mid-2000s to mid-2010s, many organisations took steps to move to standard code bases and made efforts to ‘configure rather than customise’. In addition, modern business solutions largely adhere to principles that provide a degree of separation between ‘custom’ extensions via low-code builders and greatly expanded configuration options, while also embracing cloud deployment for scalability.

The result is that the current wave of upgrades is coming from a different base starting point in terms of complexity and customisation, compared to upgrades of the past. They are also targeting different architectural end states.

Fact 7. Architecture Complexity

Transitioning from a diversified on-premises architecture to a unified cloud-based platform architecture can significantly accelerate the upgrade timeline. A ‘lift and shift’ approach, where a core system architecture is mainly left intact but migrated to a cloud architecture, can be a relatively short project; however, any solution upgrades required during the migration will significantly add to the time needed, and the key challenge of addressing legacy technology limitations is ignored.

Conversely, organisations moving from a single integrated platform to a legacy approach face complexities in dismantling existing systems and integrating new ones.

Fact 8. Little Value Gained from Customisation

Customisation of modern, SaaS solutions not only adds little overall value, it actually detracts from the solution value and adds ongoing operational cost. The propensity to customise SaaS solutions reflects a project and technology approach from a past time when software was installed, managed and supported on premise.

The extent of customisations in the existing system can complicate upgrades. While this is a well-known challenge with upgrading aging monolithic solutions, it was also noted that many organisations found a significant portion of their aged customisations were rarely used, or used by just a small group of individuals.

Surprisingly, our study found that many customisations made in the past did not return value, while leading to unnecessary complexity during upgrades.

“In short, customisation of core solutions is not just a hindrance to business flexibility – many fail to deliver the expected efficiency gains.”

This fact has significant implications for the implementation of modern business platforms. While leveraging low-code tools that separate the custom workflows and processes from the core solution helps to alleviate future challenges, the better approach is to use change management discussions early in the planning of the enterprise resource planning (ERP) refresh plan to ensure senior management oversight is focused on maintaining true to an ‘adopt don’t adapt’ principle throughout the project.

Fact 9. Integration Challenges

The need to integrate with other systems, especially in a legacy environment, can introduce delays. Organisations that do not adequately plan for integration face significant challenges, which can extend the upgrade timeline. The diversity of the core systems exacerbates integration challenges. Procuring pre-integrated platforms reduces the effort and time required during core solution upgrades. However, opting for different vendor business solutions, where ready-made integrations, often via an integration Platform-as-a-Service, are available, is also viable. Nevertheless, an ongoing effort is needed to monitor and coordinate different vendor upgrade cycles.

Fact 10. Regulatory and Compliance Considerations

Compliance with industry regulations can add complexity to the upgrade process. Organisations must ensure that the new system meets all current regulatory requirements, and provide a structured approach to adapt to future regulatory demands. Supporting the challenges of not only meeting current, but possible future regulations can extend the timeline or add significantly to only operational costs if not planned for adequately.

‘Opting for solutions that adhere to specific regulatory requirements and governance capabilities out of the box can save significant time and cost, but just as important is the ability to quickly support future demands.’

Summary of Economic Findings

ICT Operational Cost Savings

Many organisations in this study reported significant reductions in the annual costs of running their systems after the upgrade. For instance, one organisation noted that its annual cost dropped from $2 million to approximately $500,000 after upgrading its core business system.

Organisations that saw the deepest drops in their ICT costs tended to be those migrating from fragmented, aging on-premises solutions, with the bulk of the savings coming from business-as-usual (BAU) costs.

Organisations migrating from one SaaS platform to another generally did not see significant long-term operational savings, although short-term licensing deals were a factor. For these organisations, economic benefits came more from productivity gains over time.

Migration from Legacy Solutions is a Zero-Sum Opportunity for Change

The cost of upgrading an on-prem core solution to a new vendor release (such as the case with SAP HANA S4) is generally near parity with migrating to an entirely new platform. Simply staying with an existing vendor when planning a migration of a legacy environment to the latest platform does not appear to significantly simplify the migration effort, nor reduce the time needed for the migration.

This has significant implications for businesses seeking to maximise the value of their legacy on-premises core business solutions. Rather than just accepting the move to SaaS, use the upgrade as an opportunity for a complete rethink of the way the ERP is deployed and used. It is a pivotal moment where exploring new options for operating the ERP has little downside.

Efficiency and Productivity Improvements

Upgrades, particularly to SaaS products, can lead to improvements in process efficiency. One organisation reported that their month-end closing process was reduced from 22 weeks to just 2 weeks after upgrading to a SaaS financial solution. The delay was caused by a combination of having to manually pull together multiple sources of information and then work with internal and external stakeholders to correct errors. While this is a particularly strong example of the productivity improvements that can be realised, it was not unique. During the interviews, we found many examples of: simplifying processes, where multiple sources of information were merged together to form new insights and efficiencies, and where errors could be greatly reduced. These all held the potential for significant productivity improvements.

Such productivity improvements only occurred when organisations had first identified priority business processes to focus on during the upgrade.

When coupled with a systematic evaluation of which new processes will be made available by an upgrade and prioritising adoption and change management to focus on the most impactful new processes, upgrades have the potential to improve user productivity, especially for roles that require data validation and analysis.

Organisations that reimagine their processes during upgrades often find that they can eliminate unnecessary steps, leading to more efficient workflows and better resource utilisation.

The key learning is that efficiency gains and related benefits must be a critical consideration when evaluating a core solution refresh, and when prioritising the benefits to be extracted, and when prioritising change management.

Unfortunately, this study also found that few organisations evaluate or track process efficiency, making accurate calculations impossible.

‘Organisations that took the time to target specific business processes and implement change management programs as part of the upgrade tended to be those that could demonstrate tangible productivity improvements.’

Return on Investment (ROI) is too often a long-term measure

Although the initial costs of upgrading can be high, most organisations in the study anticipated a positive ROI over time. For example, one organisation projected that their ROI would become evident only by year 4, indicating a long-term financial benefit from the upgrade.

Organisations that invested in automation technologies and robust testing frameworks during their upgrades reported faster implementation and fewer post-upgrade issues, which correlated to enhanced ROI.

Staff Satisfaction and Ease of Work

Most of the organisations interviewed in this study stated that one intended outcome for the upgrade was to enhance user experience, leading to higher employee satisfaction and retention. In theory, better user interfaces and more intuitive processes can reduce training time and improve overall morale. However, in practice, few respondents were able to demonstrate such benefits, as they were not evaluated after implementation.

The Present is Not the Same as the Past

There is a substantial body of literature relating to managing large core business solution projects, most of which conform to well-established best practices regarding requirements gathering, project methodologies, constraining customisation, integration, and so forth. All of these ‘truisms’ have stood the test of time.

While the majority of past studies and books on the subject focus on how to get the project completed effectively and efficiently (on time and on budget), this study has a slightly different focus: we wished to understand:

• Has the shift to modern, cloud-based platforms impacted these long-standing truisms about core systems deployment?
• What new factors would improve the time to value from the new solutions?

We interviewed 23 Australian and New Zealand organisations to understand their recent major solution upgrades. The projects ranged from annual investments of AU$1 million to programs exceeding AU$50 million. Organisations involved range from just 500 staff, up to a little over 10,000 staff. For the purposes of normalising the study, we focused our analysis on the mid-range of projects: these are far more common, operating under extreme financial pressure and diverse complexity, and thus provide for nuanced analysis. In addition, we analysed organisations that were highly regulated environments: the public sector, education, healthcare, utilities, asset-rich and finance-related services.

“Analysis of the data made one thing clear: the present is not the same as the past.”

In 2025, several critical new factors make a striking difference to the best practices’ core business solutions projects:

• The majority of large core systems vendors are pushing for cloud infrastructure and SaaS. This not only changes the ‘ownership’ of infrastructure, but also shifts some project responsibilities to vendors.
• Modern core business platforms are architected for cloud services, demanding new approaches to integration and significantly limiting the traditional approaches to customisation, in favour of ‘low-code’ like expansion capabilities.
• The fundamental business processes managed by core business solutions have not changed significantly for decades, so the purpose of ‘requirements gathering’ needs to shift from a comprehensive (redundant) analysis to identifying new business value analysis.
• SaaS and consultation licensing structures move organisations not just from Capex to OpEx financial models, but increasingly to a utility model. This impacts everything: from the business case to the reporting models.
• While AI holds great potential to streamline processes, it also brings new risks and costs. Currently, AI remains a question mark for most core solution strategies.

‘Requirements gathering’ needs to shift from a redundant analysis to identifying new business value analysis.’

Then and Now: A Comparison of What’s Changed

Below are the well-established, traditional activities recommended for major core solution upgrades and implementations. These ‘truisms’ were synthesised from extensive literature regarding best practices for core business solution implementations¹. For each, IBRS has provided commentary on their applicability in the new era of core business platforms, along with recommendations on how they should be evolved.

Table 1: Prior Wisdom for Core Business Solution Projects: What’s Changed?

Legacy Best Practices	Today’s Realities
Requirements Gathering	Organisations have undergone requirements gathering for core business solutions multiple times over the last few decades. In practical terms, all critical business requirements for core solutions have already been gathered, and few, if any, actual changes in these requirements are being identified. We have reached a high degree of business solution and process maturity for critical business functions.Rather than redoing the exhaustive and expensive work of the past, it is best to view requirements gathering as a prioritisation effort for change management and identifying new business value from specialised modules, features or low-code, potentially including AI-enabled processes in the future.
Form a Cross-Functional Requirements Team: Involve stakeholders from all relevant departments, including executives, IT, end users, and external consultants, to ensure comprehensive input and buy-in.	The focus of a cross-functional team shifts from defining every business process to identifying gaps where work processes were not adapted to take advantage of the core business solution. The team must then map these gaps against the capabilities of the new solution to create change management and implementation priorities against an ongoing program of work (as opposed to an implementation project).Because the above activities are more inward-facing, looking for gaps in how businesses leverage their solutions, the role of consultants is significantly reduced.
Define Clear Objectives: Establish measurable goals for the ERP system that align with organisational strategy and departmental needs.	Rather than looking for ‘best of breed’ solutions to meet individual elements of the organisation’s strategy in one ‘big bang’ project, it is best to adopt a platform of business services and clear principles for how to extract the most value from these solutions.Project objectives and ‘measurable goals’ are replaced by platforms that enable continual and evolving work process innovations. As each innovation is prioritised against strategic business goals by business users and implemented incrementally, it is given its own measures.
Conduct Departmental Workshops and Interviews: Use workshops, interviews, surveys, and observation to capture detailed business requirements and pain points.	Such engagements remain essential, but their focus and structure change.Emerging platforms are increasingly breaking down departmental silos. Many of the ‘gaps’ in past efficiency gains have been a result of organisations retaining departmental silos and isolated work processes. Therefore, workshops and interviews should include a strong focus on inter-departmental processes and involve multiple departmental stakeholders.In addition, as mentioned above, there is far less need to focus on ‘detailed business requirements’ and more on ‘what work is left to be done’. The conversations for these workshops are now very different.
Map Current and Future-State Processes: Document existing workflows and design improved processes, focusing on eliminating inefficiencies rather than simply automating the status quo .	There is now far less need to map existing workflows (yet again). Where workflows have been fully adopted in a legacy platform, the process is already well-defined. Thus, effort is best spent on work processes that were never correctly defined… the workarounds staff have employed.Looking for process efficiencies is always useful, but these will be found mainly in staff’s workarounds. However, as AI weaves its way into core business solutions, additional efficiencies will become available. But these will be introduced over time, so attempting to identify all efficiency gains at the commencement of a core system implementation is impractical.Finally, mapping a fixed ideal future state against SaaS solutions that see regular (quarterly and biannual) feature enhancements is more nuanced. While a future state vision helps guide the organisation’s priorities, it should be viewed as a journey, not a destination. Following and impacting vendor roadmaps is a more appropriate activity.
Prioritise and Validate Requirements: Rank requirements by business impact, ensure they are Specific, Measurable, Attainable, Relevant, and Time-bound (SMART), and validate with stakeholders.	Prioritising and ranking requirements remain important; it shifts from being mainly about technology features to how an organisation plans to adopt and adapt to the available technology.
Document Integration and Compliance Needs: Identify requirements for system integration, data migration, and regulatory compliance.	The need for planning and documenting integration and compliance is only increasing, but also narrowing in scope. Modern core business solutions are best viewed as continually evolving platforms and master data sources. SaaS with a broad set of pre-integrated modules provide the fastest time to value, mainly due to lowering custom integration requirements. In addition, some SaaS platforms also have ‘out of the box’ integrations with specialised third party solutions, which also reduces the need for custom integration. However, to meet the governance and cyber security demands, it is now vital to understand where the organisation’s information resides, who, how, and why it is being used.Thus, integration and compliance documentation move from purely technical considerations to operational considerations.
Planning	Planning remains vital. However, in the past, many high-value projects saw planning in part outsourced to large international consulting firms. These firms have highly detailed frameworks and programs of work structures and staff with experience in implementing large ERP solutions. Most of their planning was conducted in a highly structured waterfall approach.However, these templated plans are no longer fit for purpose, given the evolution of core business technology and past sunk investments in process mapping and automation.
Establish Executive Sponsorship and Governance: Secure strong leadership support, from a steering committee, and define clear roles and responsibilities.	Executive support remains critical: it may even be more critical than ever! However, it is no longer effective to have support for a project to upgrade or implement a new core solution.Instead, it is vital to get executive support for the longer-term idea of a technology platform, from which the organisation can extract value in an incremental manner.One of the most significant factors negatively impacting the value gained from technology investment is when departments demand (or procure) solutions that have a substantial overlap with the core business platform. Mitigating the problem required strong leadership and support for the ‘platform first’ principle.
Develop a Master Project Plan: Create a detailed plan with milestones, timelines, resource allocations, and risk management strategies.	A master project plan is still needed for the technical migration and near-term change management. In particular, the plan needs to identify the principles and extent to which external parties will be involved, ideally limiting their use to the newly emerging best practices outlined in this report.Organisations also need to acknowledge that modern platforms are continually improving, so a master plan needs to be viewed as, or provide for, a rolling program of work, rather than a one-off project.
Select the Best-Fit ERP Solution and Provide Economic Modelling: Evaluate vendors for industry fit, scalability, integration capabilities, and support; consider total cost of ownership (TCO) and partner track record.	This recommendation transforms into ‘selecting the right platform’ rather than a single solution. The difference is subtle, but important. The term ‘solution’ is used to describe a best-of-breed (or best-fit-for-purpose) software package at a fixed point in time. It is based on the premise of perfectly defined requirements that remain unchanged. The term ‘platform’ is used to describe an ecosystem of tightly integrated digital business capabilities that are continually evolving, from which the organisation can draw value in the form of automation, data-driven decisions, and insights.However, the most significant change is how new core business platforms are evaluated for their financial ‘ROI’.With regards to ROI, many upgrades of ERPs to core business platforms cannot easily be tied to new business value (i. e., more efficient digital processes or new automations) that provide a measurable productivity gain (i. e., requiring fewer staff). While there will be examples, especially in the area of self-service portals, the reality is most organisations’ upgrades are a close like-for-like upgrade, with the improvements being usability. In previous economic modelling2, IBRS noted that most direct savings when moving to SaaS come from reduced BAU and infrastructure costs, resulting in ‘investment humps’ for migration: high costs during the migration that take three to five years to cover.To get full value from new platforms, organisations need a formal, ongoing process to find new ways to extract value from the investment. It requires a shift to a ‘continuous innovation cycle’, which is supported by economic tracking. This concept is explored in more detail later in this report.In addition, modern business platforms continually release new data-intensive features, such as intelligent analytics, recommendation engines, and decision support systems, as well as agent-based AI. In many cases, these are offered as add-ons with consumption (per-use) licensing models. Therefore, traditional TCO models fail, since the cost of running the platforms is elastic and scales with the business demands for such new capabilities.In summary, the selection of a new business platform is based on very different considerations from the past. While rigorous selection processes are needed, and ROI and TCO modelling have a place, organisations need to look at the longer-term impact and operating models of migrating to a new platform.
Set Up Project Management Office (PMO): Implement robust project governance, using milestone-based (waterfall) or agile methodologies as appropriate.	A PMO remains an essential factor in successful core business platform migrations; however, the structures may differ. As detailed above, the role of department stakeholders changes, and the focus of the PMO extends beyond migration to the ongoing business practices that continually extract value from the new platform once it is in place. In addition, the PMO is responsible for working with the business to prioritise the implementation of features over time in line with change management, targeting specific ‘gaps’ and ‘workarounds’.The PMO focus shifts far more to business behaviour and processes than ‘getting the new tech installed’.
Allocate Adequate Resources: Ensure sufficient budget, skilled personnel, and time are dedicated to the project.	It is no secret that the majority of large business solution implementations run overtime and over budget. So clearly, the ways we attempted to do this in the past were flawed.An IBRS analysis of why upgrade and migration efforts suffer from such overruns was striking: it is mainly due to the ineffective use of consulting services. This study suggests that the use of large consulting firms to guide core system upgrades or migrations can significantly extend the time required and, consequently, increase the costs. More specifically, consulting firms that have ‘well-proven’ and templated implementation plans based on the legacy best practices discussed here, overbake what is needed.Upgrades or migrations to modern core business platforms require a narrow focus on ‘what’s missing’ (the gaps and related change management), as well as a long-term commitment to continual innovation and value extraction from the platform.We explore options for team structures and staff later in this report.
Plan for Change Management: Develop a comprehensive change management and communication plan to address resistance and foster user adoption.	In the past, change management was an activity that occurred relatively late in the program, typically after the new platform was selected.In the new age, change management is an input to both the selection of new platforms and the prioritisation of which features and services will be implemented over time.As discussed in Phase 1: Requirements Gathering (above), change management is closely tied to exploring the features of the previous (legacy) solutions that were missing or underutilised, and awareness of these gaps drives many decisions for the upgrade program.It is no longer enough to ‘plan for change management’. Change management is the plan.Think of it this way: if you are not planning to change the organisation, where is the new business value for a new platform? What’s the point?Change discussions must come first and guide the program.
Execution	Rolling out the new core business platform remains a costly and risky activity. However, focusing on the business value gaps remaining in the legacy solution helps to keep the scope narrow.Furthermore, keeping the planning and control tightly within the organisation, while leveraging a mix of consulting capabilities in specific areas, helps keep the migration timeframe and budgets on track.
Phased or Big-Bang Rollout Decision: Choose between phased (module-by-module) or big-bang (all-at-once) deployment based on organisational readiness and risk appetite.	This remains a valid question for organisations, but it now takes on a new dimension: master data as the end-state. Where the upgrade or migration has minimal impact on the structure of master data, phased implementations are generally more palatable.In addition, the ability to ‘lift and shift’ on-premises solutions into cloud infrastructure and then parallel run a SaaS version also offers new opportunities.Where the master data structures between the two solutions are significantly different, big bang approaches become more attractive, although most organisations still retain the legacy solutions running in parallel for several months.
System Configuration and Customisation: Tailor the ERP system to fit business processes, configure modules, and develop necessary customisations while minimising unnecessary complexity.	A major cause of cost blow-out is dealing with customs. This is not a new issue, but with SaaS platforms, it has reached a critical point. The modern approach is to adopt and adapt to the core business platform’s modules, configuring each to the business sectors.Customisations are to be viewed as ‘differentiated processes’ and are replaced with low-code automations and forms, abstracted from the core platform code, but leveraging its data. The term ‘differentiated’ is essential here, as it implies that the customised process provides a significant competitive or efficiency gain; and it rejects ‘that’s the way we do it’.An important consideration for the new mode for customisation is that it plays a vital role in an organisation’s ‘continual innovation cycle’ program, by allowing non- or semi-technical staff to explore ideas for new processes. Therefore, ‘customisation’ (and indeed configuration) is moving away from the technology group and a set-in-stone activity during the migration, to an ongoing program led by the business. Of course, this demands formal governance.
Data Migration and Validation: Cleanse, map, and migrate legacy data; conduct trial migrations and parallel runs to ensure data integrity .	This is one area where a vendor or specialist consulting firm truly excels.If upgrading one version of a vendor’s product to the new version, the data migration work is often most cost-effectively accomplished by the vendor, increasingly as part of a ‘packaged upgrade program’ such as TechnologyOne’s SaaS Plus.For migrations between different products or platforms, utilising specialist consulting firms with prior experience in such migrations is the optimal approach.
Comprehensive Testing: Perform unit, integration, and user acceptance testing (UAT) to validate system functionality and data accuracy .	Testing and confirming data accuracy remain crucial activities. Much of this activity can be delegated to the data migration and validation partner (mentioned above), though the governance and final sign must remain internal.However, in modern core business platforms, technical level testing is less critical than UAT, and identifying gaps in staff knowledge of the platform and how it should be uniformly used for specific tasks is more important.
User Training and Super User Model: Train end users and designate departmental superusers to provide ongoing support, offering role-specific, hands-on training.	These activities should begin even before implementation. They are a prerequisite for implementing modern platforms.
Change Management Execution: Maintain proactive communication, address concerns, and provide support to drive adoption.	As discussed in Phase 1, change management is not a ‘tack-on’ once the decisions are made, but a fundamental input to the program plan.The communication shift is from explaining why a move is necessary to being informed about what the move will entail and how training and change actions will be prioritised around weaknesses (gaps) in how the legacy solutions were used.
Monitor and Support Post-Go-Live: Establish a support structure for rapid issue resolution, monitor KPIs, and solicit feedback for continuous improvement.	While monitoring and supporting users post-‘go-live’ remains essential, the introduction of a continuous innovation cycle is needed. It must clearly articulate how staff can drive new ideas for maximising value from the platform while making their working lives easier.
Ensure Security and Compliance: Implement robust security controls, access management, and compliance monitoring from the outset .	One of the benefits of modern SaaS platforms is that their security is primarily managed by the vendor. Security has shifted from a focus on technical excellence to contractual obligations. The implementation of single sign-on (SSO)and MFA is recommended.However, for organisations with high compliance demands (public sector, healthcare, education, utilities, finance, etc), the issue of digital sovereignty should be considered.While data geolocation (where the core business platform data is physically stored) is a primary issue, digital sovereignty encompasses the location where data is analysed and processed (a significant concern for AI-powered features), as well as the location of staff managing the vendor’s infrastructure and their credentials, and any third parties the vendor may include in their own operational stack.

What Makes the Biggest Difference?

The evolving role of consulting services

IBRS’s analysis of the factors impacting upgrade and migration projects resulted in a surprising finding: one of the most significant factors affecting the time and cost of such projects is how consulting firms are leveraged and the roles they play.

On the surface, the above claim contradicts the conventional wisdom that external consultants – especially tier 1 global firms – bring a wealth of experience and specialist expertise to projects. They do. But while consultants undeniably bring expertise, their effectiveness hinges on a deliberate strategy of engagement, rather than a blanket reliance on traditional, large-scale models.

From an analysis of the case studies, it was noted that the costliest migrations often had large tier 1 consulting or integration service firms leading the charge (pun intended) and shaping both strategy and implementation plans. More concerning, these programs were more likely to have budget overruns.

A deeper analysis suggests that in these cases, tier 1 consulting firms relied heavily upon existing IP, well-established frameworks and traditional engagement models. However, these very strengths no longer translate well with modern SaaS platform implementations, as discussed in the Table 1, above.

Table 2: Summary of Case Studies Using Tier 1 Consulting Firms

Case Study	Project	Budget	Budget Overrun or Underrun (rounded)	Staffing as% of Cost	Tier 1 Consulting Fees (rounded)
Case Study 01	Case Management Migration & Uplift	$12,000,000	0	23 %	50 %
Case Study 04	On-premises Student Management System to SaaS Migration	$16,000,000	25 %	33 %	20 %
Case Study 12	HCM Upgrade Functional Enhancement	$3,500,000	30 %	11 %	35 %
Case Study 15	ERP Reimplementation	$12,000,000	40 %	8 %	45 %
Case Study 16	On-premises to SaaS Office Productivity Migration	$2,500,000	20 %	16 %	20 %
Case Study 17	Legacy ERP Upgrade	$20,000,000	20 %	4 %	55 %
Case Study 18	Federal Public Sector Agency Upgrade	$5,500,000	20 %	12 %	40 %
Case Study 19	ERP Upgrade	$10,500,000	15 %	16 %	35 %

Is it them… or are we just accepting the status quo?

However, in case study 01, we saw a noteworthy exception. This organisation engaged a tier 1 system integrator consulting firm with a creative time and materials contract that retained 25 % of the billable fees in escrow. This model drove specific behaviours for both the client organisations and the IS firm, and necessitated a modern approach to the migration.

Given the correlation regarding project fee sizes, cost overruns, and the use of tier 1 consulting firms for providing strategy and program management services, one could argue that there is little incentive for tier 1 firms to change their approaches or take on the shared responsibilities and risks detailed in case study one. While the market has moved on, there has been no incentive for the well-established consulting firms to alter their practices.

Even so, it is clear that the tier 1 firms are more than capable of entering into a modern shared risk model that is well aligned with the new realities of modern core business platforms. All of the major international firms tout their willingness to engage in shared-risk, reward contracts. However, taken alone, these risk/reward models do not address the key problem: implementing modern core business upgrades in a modern, evolved way.

The impetus is now on client organisations to insist on these new and creative engagement models, while retaining tight control over early stages of the program: in particular, strategy, board-level communication and support, requirements gathering, and platform selection.

A Better Team Structure? What the Data Suggests.

The case studies suggest that a specific mix of vendor and consulting services is optimal for organisations migrating and modernising their core business solutions. The optimal resource mix involves a strong in-house team leading the project, supplemented by several smaller, highly specialised consultancies for specific tasks, and the vendor for guidance and configuration support. Clearly, this mix will vary based on the size, maturity and budget constraints of client organisations, but in broad terms. The optimal mix is not about a fixed percentage but about strategically leveraging each group for its unique strengths.

Internal Team and Project Management

A strong internal team leading the project is crucial for expediting the process. This team should focus on project and change management, working closely with business stakeholders. As mentioned earlier in this report, change management moved forward to the planning stage, being used to identify and prioritise business processes that were never fully automated in previous ERP efforts. The most successful implementations in this study involved close engagement with line-of-business executives throughout – and early – in the project, and sometimes rotating business staff into the implementation team to assist with prioritisation and design.

The best uses for internal staff include:

• Project Leadership and Management: Guiding the project, making key decisions, and ensuring alignment with business strategy.
• Change Management and Training: Facilitating user adoption, creating training materials, and providing ongoing support.
• Core Systems Knowledge: Providing context and requirements from the business perspective to external partners.
• Post-Implementation Support: Handling the transition to ‘business-as-usual’ and ongoing operational support.

From the case studies in this study, the fastest ROI and smoothest implementations occur when there is a strong Executive Sponsor, and a dedicated internal staff driving execution.

Conversely the slowest ROI and highest cost overrun is where there is no strong project sponsor, inadequate dedicated resources (doing the project ‘as well as’ BAU), or worst case – where it is effectively ‘outsourced’ to a tier 1 consultancy to ‘build and run’.

Vendor Support

Two scenarios impact the role vendors will play: migrating from one vendor’s platform to a completely different vendor platform; upgrading from a vendor solution to its latest version, increasingly to the vendor’s SaaS platform.

When migrating to an entirely new platform, the role of the vendor is more limited, with the focus being on mapping product features to the client’s needs, training the trainer programs, configuration and testing.

When migrating from a vendor’s legacy solution to its latest version, vendors’ roles can be more expansive. Several ERP vendors are now offering ‘fully managed migration’ services, which generally handle the majority of technical tasks for the migration. In theory, such services can accelerate the migration process. However, this accelerated delivery is possible only when the internal teams have strong project management and a close working relationship with business stakeholders, as discussed above.

The best use for vendor support is to:

• Mapping the Product Features to Client Priorities: Working with the project leadership and change management teams to link specific features, work processes and modules to the implementation plan.
• Implement and Configure the Core Product: The vendor has the deepest expertise in their own software and is best suited to handle the technical setup and configuration.
• Data migration: especially when upgrading from on-premises to SaaS platforms.
• Train the Trainer: Working with the technology and business stakeholders to not only train platform administrators, but also working with change management teams to support the development of process/role-specific training programs based on previously identified priorities.
• Provide Tier 3 Technical Support: Resolving highly specific and complex technical issues that internal teams cannot address.
• Operational Support: Providing temporary support for post-go-live activities while the internal team ramps up.
• Developing custom workflows: working with BAs or directly with business stakeholders.
• Reporting and Analytics configuration: working with BAs or directly with business stakeholders.
• Full Managed Migration: Some vendors can provide a broad range of services for the upgrade or SaaS migration of their platform. Such programs align well with the modern approaches outlined in Table 1. However, for these engagements to be effective, client organisations will still need to lead the early change management and process gap analysis, to provide both the vendor and the business with clear priorities for change activities that can be mapped to the platform’s configuration and ongoing roadmap.
• Tier 1 Consulting Firms: The high costs of tier 1 firms are justified when they provide expertise that is not available internally. The best uses for tier 1 consultants include:
  • Complex Implementations: Providing experienced staff with the technical re-implementation of highly customised or intricate systems.
• Tier 2 Consulting Firms: These firms typically offer more tactical and hands-on support than their tier 1 counterparts. They are often used for:
  • Resource Augmentation: Providing specialised skills on an as-needed basis to fill gaps in the internal team. They are particularly effective for:
    • Data preparation, especially when migrating between two different vendor solutions
    • Integration development
    • Developing custom workflows: ideally using the target platform’s low-code environment.
  • Functional Implementation: Handling specific modules or phases of a project, such as data migration or integration.
  • Operational Support: Providing temporary support for post-go-live activities while the internal team ramps up.

The Relationship Between Project Timeframe and Team Structure

The structure of teams also affects the time required to complete projects. The complexity of a project plays a significant role in the time needed for a core system implementation.

However, given that the case studies included in this report were generally mid-sized organisations, many of which were transitioning from on-premises to SaaS efforts (the norm in the market), we believe the correlation between team structure and time provides some helpful insight – at least for these types of core business solution migrations.

Programs where internal resources, backed with vendor migration services, correlate to shorter implementation timeframes. In contrast, longer implementations correlated with greater use of consulting services.

A deeper analysis of the case studies also suggests that in the programs, when vendors took on a larger role and saw faster completion, the projects were more often a migration from the vendor’s legacy on-premises version to their SaaS platform. The assumption is that the data structures and services closely align, but this was not always the case.

An important trait that accelerated upgrade work was the presence of pre-integrated solutions. Where organisations had a common platform covering many different business functions (an ERP in the classic sense), the migration was often shorter. However, this was only the case when customisation was minimal or was intentionally ignored. This is what is meant by complexity when planning migrations. Such pre-integrated, minimally customised solutions were more common in scenarios where the organisation was moving from a vendor’s legacy on-premises solution to the vendor’s newer cloud solution.

Another notable trait was that the organisation did not perform a ‘start from scratch’ requirements gathering program, instead focusing more on addressing any process gaps remaining in the legacy system. The migration scope was kept narrow, focusing mainly on potential improvements to business processes (leveraging new functions) rather than going over core business activities that were already automated and working well.

Interpreting the chart:

This chart provides datapoints of projects reviewed in this study. The points represent the intersection of the length of project time to implement a new core platform versus how much of the project (in terms of human resourcing) a specific category of consulting firm played. For example, the vendor point at the 60 % and 3 month market was a project where a vendor was a major player in an ERP uplift, and represents a compelling example of heavy reliance on a vendor partner. Conversely, the tier 1 vendor points at 65 % and 55 % involvement at more than 35 months of project time show examples of where heavy use of tier 1 consultancies saw extremely long timelines.
The critical aspects of this chart are the trend lines. The downward swing of the vendor (yellow) and internal (blue) trend line shows that as vendor consulting services and internal resources are less involved in a project, overall project times expand.
The case studies in this report do cover a range of different organisation sizes and complexities. However, they were not so far apart as to materially impact the results of this chart.

Team Structure of Budgets

In the case studies, there is a strong correlation between staying within budget and the structure of teams. As illustrated in the chart below, the greater use of tier 1 consulting was more strongly correlated with budget overruns. The use of vendors for rapid migration services, and the tactical use of tier 2 specialised consulting services correlated to staying on budget.

The chart also has two ‘outstanding’ data points, which represent a failed project: it had a very low percentage of involvement of internal resources and was mainly outsourced. It is a cautionary tale.

Interpreting the chart:

Similar to the previous chart showing project time against the resources used, this chart provides datapoints of projects reviewed in this study. The points represent the intersection of the extent of budget under or overrun for a new core platform versus how much of the project (in terms of human resourcing) a specific category of consulting firm played.

Needless to say, budget underruns were rare. The two points (vendor and internal resources) showing a significant budget underrun (–60 %) relate to a project where the initial budget set aside for an ERP implementation was based on a SAP implementation, but the organisation opted for a narrower ERP implementation of just the TechnologyOne financial and related modules, with considerable licensing and implementation effort minimisation as a result.

Where vendors, smaller tier 2, and internal resources were heavily involved (in a variety of mixes) the projects tended to run on, very close to budget.

Also unsurprisingly, given the correlation between length of time taken for projects and tier 1 vendors, as tier 1 vendors took on an increasing role in the project, so too did budget overruns occur.

ICT Operational Savings: On-Premises Legacy to SaaS Migration

IBRS noted that ICT operational savings when migrating from on-premises to SaaS solutions varied greatly between organisations. Examples from our interviews include:

Examples

High-End of ICT Operational Savings

• Federal Government Agency: a substantial decrease in their annual operational expenditure, with costs dropping from approximately AU$2 million per annum for their previous system to around AU$500,000 per annum for the new solution. This example represents a significant fourfold reduction in running costs.

Mid-Range of ICT Operational Savings

• Local Government: Saw a 10 % to 15 % saving specifically in solution administration costs and operational savings after migrating from a legacy on-premises solution to a SaaS platform. The estimated annual costs for their legacy solution’s support staff were AU$1.4 million, excluding software fees, with the new platform saving 1.5 FTEs, or approximately $160,000 annually.
• Higher Education: Noted a saving of one full-time equivalent ICT staff member (a saving of $90,000 annually) after migrating from a legacy human capital system (HCM) solution from an on-premises deployment implemented in 1997 to a cloud IaaS in the cloud environment. Previously, the HCM solution required two full-time staff members to administer and maintain it.
• Another organisation that migrated away from a ‘monolithic on-premises SAP stack’ noted that historically, expenditure on incremental patches and upgrades alone could constitute 30 % to 40 % of the total run cost of the legacy platform. Moving to a ‘lean core ERP'(financials) solution complemented by best-of-breed SaaS applications resulted in incremental upgrades being less expensive, alongside savings gained from infrastructure rationalisation. However, the savings were offset by significantly higher subscription costs, resulting in an operational cost saving of around 7–10 %.
• Higher Education: Reported that their new SaaS-based student management (SMS) system took less time to administer and enabled automation that reduced process steps, resulting in an estimated 30 % reduction in operational costs (AU$220,000 annually) with the equivalent of 2 ½ FTE saved in the ICT group.

Low End of ICT Operational Savings

• Public Sector Agency: While it reduced the number of FTEs and infrastructure needed to run a financial solution in an on-premises environment, this organisation noted that the licensing costs of running and administering the environment increased from AU$1 million to AU$1.2 million when the new SaaS license was introduced. A deeper inspection of this situation revealed that the reason for the on-premises version of the solution was almost ten years out of date, and thus, upgrade and maintenance costs were not being factored in. In addition, the new SaaS solution included additional business functions, or modules, not present in the prior solution.

These examples underscore the finding that the primary source of operational cost savings was the reduction in effort, infrastructure, and complexity associated with managing and maintaining aging or fragmented on-premises systems.

Operational Maturity Matters

Observations

Across the cohort of organisations interviewed, IBRS noted that the level of operating maturity of organisations running legal on-premises solutions directly and beneficially impacts the savings from migrating to a SaaS platform.

At first, this observation seemed like a paradox: surely a well-run, highly efficient environment would be operating at the highest level of cost-effectiveness? While true, it also meant that the organisations generally had clear visibility of their full operating costs and, importantly, continually ran major upgrades, applied patches promptly, while also running technical and user-based testing within a formal change management program. By being more mature, these organisations were investing more resources to keep their on-premises platforms up to date. Few would be considered ‘legacy’ other than the length of time they had been used within the organisations.

When these organisations migrate to SaaS platforms, they have a clear understanding of the prior operational costs and resources. The continual upgrade cycles of SaaS platforms eliminate the most significant cost in maintaining these aging solutions – managing the upgrade and testing regimes. The hardware and patching maintenance were a far more minor component in the return on investment calculation.

• Unless your organisation has a high level of operational maturity, with deep insights into the costs of maintaining on-premises infrastructure, managing and continually updating security controls, running audits, and running upgrades and test cycles, calculating the economic returns for migrating to SaaS will be underestimated.
• It is not feasible to rapidly retrofit ICT operational maturity when planning a migration from a legacy on-premises environment to a SaaS platform. Nor is it practical to attempt to gather prior operational costs retroactively. Generally, the data needed was not captured in a form that is viable. At best, estimates can be made. Therefore, organisations in this situation should focus less on costs and savings and more on the service and security benefits of SaaS: namely, fully managed upgrades, test and change management.
• Migrating from on-premises environments to SaaS is an opportunity to improve ICT operational efficiency. When planning such a migration, set aside time and budget to review your organisation’s ICT operating model, including how the ICT group will work with the organisation to prioritise new features or demands for new services, who will perform business-level configurations and how upgrades will be tested and approved. Importantly, determine the operational metrics to be captured and how such data will be utilised to continually improve ICT operations.

ICT Operational Savings: Cloud-Hosted Platform to SaaS Migration

When migrating from one cloud platform to another, the sources offered fewer detailed examples, focusing on long-term operational cost savings. The most common type of migration involves organisations moving from a cloud-hosted version of a vendor platform to the SaaS version of the same platform. In almost all cases, this type of migration was part of a longer-term strategy to ‘migrate in steps’ from an on-premises environment, with a ‘lift and shift’ to the cloud being an interim step.

Costs were noted as being lower during this initial phase; however, it was acknowledged that a subsequent ‘uplift’ would be necessary to fully exploit the new platform’s capabilities, implying additional effort and potentially higher costs beyond the initial migration. Short-term licensing deals offered by vendors were also identified as a factor influencing the initial cost profile of a migration.

Single Platform Approach

Integration and Cohesion

A single platform approach often leads to better integration and cohesion among various business functions. For instance, organisations that opted for a unified platform reported fewer integration challenges, which can streamline processes and reduce costs associated with managing multiple systems. This cohesion can enhance data consistency and improve overall operational efficiency.

Cost Management

Organisations using a single platform typically experience better cost management. The reduction in integration costs and the need for fewer external consultants can lead to significant savings. For example, one organisation noted that moving to a unified platform helped manage costs better and reduced the complexity of training and upskilling staff.

User Experience and Training

A single platform can simplify user experience and training. Employees only need to learn one system, which can lead to faster adoption and higher satisfaction rates. This was evident in organisations that reported improved user satisfaction and reduced training times when transitioning to a single platform.

Scalability and Future-Proofing

A unified platform is often more scalable and adaptable to future business needs. Organisations can more easily implement new features and functionalities without extensive rework, resulting in long-term economic benefits.

Organisational Change Management

The single platform approach can facilitate better organisational change management. With a cohesive system, organisations can more effectively communicate the benefits of the upgrade to employees, leading to higher acceptance and engagement.

Mixed Solution Approach

Flexibility and Specialisation

The legacy approach allows organisations to select specialised solutions that best meet their specific needs. This flexibility can (though in hindsight does not) lead to enhanced functionality in certain areas, as organisations can choose the most effective tools for each business function. However, this can also introduce complexity in managing multiple systems.

Integration Challenges

Organisations that adopt a mixed approach often face significant integration challenges. Integration costs can be as high as 35 % of the project (checking this point). The need to integrate various systems can lead to increased costs and extended project timelines. Organisations reported that their projects ran overtime due to the complexities of integrating disparate systems.

Higher Total Cost of Ownership

The TCO can be higher with a mixed approach due to the need for additional resources for integration, maintenance, and training across multiple systems. This was highlighted in discussions where organisations noted that while they achieved specialised functionality, the costs associated with managing multiple vendors and systems were substantial.

User Experience Complexity

A diverse system landscape can complicate the user experience. Employees may need to navigate multiple interfaces and systems, which can lead to confusion and lower satisfaction rates. This complexity can hinder user adoption and require more extensive training efforts.

Risk of Customisation

Organisations that pursue a mixed strategy may be tempted to customise their systems extensively to meet specific needs. This can lead to increased costs and complexity, as well as potential issues with system upgrades and vendor support.

Conclusion

Upgrading legacy core business solutions to SaaS platforms presents a significant opportunity for economic advantage, but success hinges on a nuanced understanding of modern implementation approaches. The analysis in this study reveals that while external consultants offer expertise, a blanket reliance on traditional, large-scale models often leads to budget overruns and extended timelines.

The most successful migrations correlate with a strong internal team leading the project, supplemented by specialised vendor services and targeted engagement with smaller, highly specialised consulting firms. Key recommendations include:

• Prioritise Internal Leadership: Empower a robust in-house team for project and change management, fostering close collaboration with business stakeholders from the outset.
• Strategic Vendor Leverage: Utilise vendor-provided migration services and expertise, especially for upgrades within the same product family, to accelerate technical tasks.
• Targeted Consulting Engagement: Reserve tier 1 consulting firms for highly complex, differentiated processes where unique expertise is genuinely essential, and only where tier 2 capacity is not available. Employ tier 2 firms for tactical support, resource augmentation, and specific technical tasks like data preparation and integration development.
• Embrace New Engagement Models: Organisations must insist on creative, shared-risk contracts with consulting firms to align incentives and drive modern approaches to implementation.
• Focus on Business Process Improvement: Rather than ‘start from scratch’ requirements gathering, prioritise addressing process gaps and leveraging new SaaS functionalities for tangible business improvements.
• Understand Operational Maturity: Accurately assess the costs of maintaining legacy systems to avoid underestimating the economic returns of SaaS. For organisations with lower operational maturity, focus on the service and security benefits of SaaS.

Footnotes

1. See Appendix 2: Additional Readings
2. Economics of SaaS: Too Big To Ignore, IBRS 2020.