English (UK) 
Magyar 
Deutsch Would you like to replace your existing ERP system? We’ll show you why it pays to involve an external partner in such projects, and how to avoid the most common mistakes already during the planning phase.
Summary
In many SMEs, a mature testing methodology is often missing: testing lives in Excel files and in the minds of business users or regular IT project participants, while key users try to manage the task alongside their day-to-day work. Testing is frequently carried out in an ad hoc manner - there are no releases, developers fix the code “on the fly,” and key users test it immediately. All of this may take place simultaneously across 8-12 teams (sales, procurement, logistics, production, finance, etc.), overwriting one another’s test data and test processes. Meanwhile, ERP consultants continuously adjust system parameters, and operations colleagues install patches or restart systems on the fly.
An external partner can help design the test strategy and test plan, define testing levels and roles, and train and coach the internal team so that the methodology remains sustainable in the long run.
The testing budget typically accounts for only 20-30% of the total project budget - but it is crucial. It costs far less than a delayed go-live, a faulty migration, or an operational outage after go-live, along with the extra testing cycles required as a result.
Table of Contents
Why is Replacing an ERP System Often Difficult?
SMEs today face both capacity shortages and rising business expectations. It’s common for older ERP systems to be outdated, functionally limited, and difficult to develop further. Typical questions arise: does an SME really need such a large system? Is there enough budget? Can testing be handled entirely in-house?
Based on DIHK -Umfragen binden die meisten KMU externe IT-Dienstleister in ihre Digitalisierungsprojekte ein. Dennoch wird das Budget häufig fast vollständig für Systeme und Implementierung aufgewendet, während strukturiertem Testen kaum Beachtung geschenkt wird.
Without a well-thought-out and sustainable software quality assurance approach, issues can easily arise that undermine the success of the entire project..
Problems That Will Not Be Solved Without a Good Testing Methodology
Common problems during ERP implementation include:
✘ Project delays because testing only happens when there’s time for it
✘ A lack of clear test plans
✘ No defined entry and exit criteria
✘ No fixed test cycles or code freezes: continuous customization and patching occur in parallel, making it difficult to track when and why defects appear
✘ Business areas testing independently and overwriting one another’s test data or processes
✘ Defect management handled through spreadsheets, emails, and scattered lists instead of a test management system
✘ Incorrect data imported into the new system because, although migration is executed technically, there’s no migration test strategy or meaningful business validation behind it
✘ No go-live simulation with real processes, no performance checks, and no rollback plan - potentially stopping invoicing, production, or financial closing after go-live
What Is the Solution to These?
At TestIT, every project starts with setting up a transparent testing methodology, which already prevents most of the problems listed above. This includes a well-defined test plan, structured defect management, integration and user tests built around critical business processes, migration checkpoints, and an objective measure of go-live readiness.
Why Internal Experience Alone Is Not Enough?
Replacing an ERP system is usually a rare event in a company’s life. It’s therefore unrealistic to expect the organization to have all the expertise needed for replacing such a complex system. Key users and business experts know what they want, but not necessarily how to test in a way that provides measurable, decision-ready results. Testing also consumes significant human resources. Without a deliberate testing methodology, testing often becomes the first victim when resources are tight. That’s precisely why bringing in external, scalable testing capacity makes sense. For an SME, a smaller but professional baseline is usually enough - providing structure, methodology, and the right tools.
At the same time, key users remain vital: they know business processes, company specifics, and master data best. An experienced tester can make their work far more efficient - for example, by designing reusable test cases and reducing time spent creating test data or prerequisites - and take over repetitive test execution tasks.
It Can Work on a Smaller Scale Too - Options When the Company Budget Is Tight
From an economic perspective, testing quality largely determines how well an ERP investment pays off and meets initial expectations. An insufficiently tested ERP system can lead to months of delay (extra consulting days, internal workload, exhausted key users), severe post-go-live disruptions (missed deliveries, invoicing issues, halted production), or expensive “firefighting” rounds later.
Even part of these hidden costs can exceed what professional testing support would have cost in the first place - especially in projects like SAP S/4HANA or proALPHA implementations, where processes span many business areas.
Without proper testing, an ERP project becomes an expensive and risky experiment: it might succeed - or require even more money to fix afterward. A structured methodology, a test management tool, and a risk-based plan ensure the same project and license budget deliver a far more reliable system. They also offer an objective, transparent view of test progress - key for representing the company’s interests toward the ERP vendor (for example, proving what still needs to be delivered or who is responsible for a particular defect).
External testing support is not a “luxury investment.” According to Bitkom data, more than half of German SMEs already use external IT service providers in digitalization projects, with many including testing and quality assurance.
ERP Implementation Project Plan: When and Where Does Testing Come In?
In many project plans, testing appears in only one place - right at the very end. In reality, the ideal approach is to have it present from the requirements phase onwards. Below is an example where the expected duration of each phase is realistically assessed at the very beginning of the planning process, and where testing genuinely contributes to the success of the project - protecting it from numerous risks.
Important: If testing is not planned consciously in phases 1-3, rushing and delays are almost guaranteed later.
Does Replacing an ERP System Really Take This Long?
While many estimate such projects at 1.5-2 years, TestIT’s experience shows that in practice they can easily last 3-4 years. However, this timeline can be significantly shortened by early involvement of an external partner and thorough planning. These two factors help avoid overly optimistic or pessimistic schedules and enable a realistic, manageable project plan - reducing surprises later on.
Where Can We Save Time?
Time can often be gained between phases 3 and 4. Waiting for the entire concept to be finalized before starting implementation causes delays. A rolling approach - where planning and configuration of the first modules run in parallel - allows faster progress, but only if the test strategy has already been completed in phase 3.
Similarly, overlapping phases 4 and 5 (rolling testing) lets teams begin testing completed modules while others are still being implemented. This saves time but demands strong methodology and often external coordination support. It also helps familiarize employees with the test management tool earlier, making later, larger testing phases smoother.
Which Areas Can an External Testing Expert Support?
An independent external partner plays an important role both in establishing sound foundations and in the final assessment. Typical areas of involvement include:
1. Developing a Testing Methodology Tailored to Company Processes
Helps define in practice:
- test levels (module, integration, user, go-live simulation)
- responsibilities (RACI)
- test case templates (simple but consistent)
- defect handling (priorities, statuses)
2. Creating the Test Plan
A clear test plan:
✔ fits into the overall ERP project schedule
✔ defines when, what, and who will test
✔ includes entry and exit criteria
✔ makes risks and test cycles transparent
3. Introducing a Test Management Tool
The next level is implementing an SME-appropriate tool (e.g. Jira-based solutions, SpiraTeam), which:
- replaces Excel- and email-based tracking
- provides a single view of testing status
- enables transparent management reporting
4. Testing Coaching for Key Users and IT
The goal is for key users to learn how to create usable, reusable test cases, and for IT to manage testing independently during future rollouts. Coaching builds internal competence and reduces long-term external dependency.
5. Go-Live Readiness Assessment
Before the first major go-live, an independent, objective review is essential. It:
- analyzes completed tests, coverage, and defect statistics
- evaluates open defects by risk
- provides a data-driven recommendation on whether the system is ready for launch
This enables management to make decisions based on evidence - rather than gut feeling.
Test management is the planning, execution, control and monitoring of testing processes...
Professional Testing Today Is Only Possible With the Right Test Management Tool
A professional testing provider is familiar with multiple test management tools and helps choose the one that best fits the company’s size and project, while also training the team to use it effectively.
This is often the point where traditional Excel-based testing gives way to proper tool-based management. Excel methods quickly reach their limits once a project involves many modules or rollouts. Maintaining discipline and consistency in Excel demands disproportionate time and effort. By contrast, an SME-friendly test management tool quickly pays for itself through fewer delays and fewer defects.
PROS AND CONS: Excel vs. Test Management Tool
Aspect | Excel list | Test management tool (e.g. Jira, SpiraTeam) |
Transparency | Manageable up to 1-2 sheets; chaotic beyond that | Centralized view, searchable, filterable, project-level visibility |
Versioning | Multiple versions emailed around | Built-in version control, change log |
Defect management | Test cases and defects mixed manually | Structured defect tickets with statuses and owners |
Status reporting | Manual summaries, high error risk | One-click reports, management dashboard |
Regression tests | Heavy copy-paste, poor reusability | Test packages, repeat execution with one click |
Multiple rollouts/countries | Separate Excel for each rollout | Manage multiple projects/versions in one system |
Implementation effort | Immediate start, but high hidden labor cost | 1-2 months setup, then major time and risk reduction |
What Else You Should Know: The RACI Matrix - Who Does What in Testing?
One of the biggest pitfalls in ERP projects is unclear testing responsibility. The simplified RACI matrix below focuses on testing roles only. The external testing partner helps align IT and business roles, giving management a transparent, fact-based view of project risks.
Short Checklist for IT Managers Before an ERP Transition
If management asked whether your new ERP system is ready to go live - what evidence could you give?
- Is there a written test strategy and plan known to both business and IT?
- Has someone been designated with final responsibility for testing?
- Are you using a test management tool, or are you still tracking everything in Excel?
- Have key users received methodological support for testing?
- Have critical processes (order-delivery-invoicing-accounting, production, inventory) completed at least one full integration and user test cycle?
- Has there been a go-live simulation with realistic test data?
- Is there a rollback plan in case serious issues arise during go-live?
- Can you provide a measurable, data-based statement of what risk level your go-live entails?
If these points sound familiar, you can request a short risk assessment from us to uncover testing gaps.
ERP System Testing - First Free Consultation with TestIT
Following the initial free consultation, we propose a short assessment project, during which we:
- define the high-level timeline and scope of the implementation
- review required system integrations
- determine which business areas and processes the ERP must support
- analyze the current testing methodology, process, and tools
- review a sample of existing test cases (if available)
The assessment is based on documentation review and consultations with the project manager, IT operations, key business users, and the test manager.
As a result:
✔ We summarize the maturity of the current testing processes and identify improvement areas.
✔ We recommend the appropriate testing levels.
✔ We provide a high-level estimate of testing time and team size.
✔ We define a high-level testing schedule.
FAQ
How Long Does an ERP Implementation Take for SMEs?
It depends on company size, number of modules, and amount of custom development, but SMEs should plan for 2-4 years from requirements definition to a live system. Cutting testing too short or starting it too late usually means a longer and more expensive post-go-live phase due to unexpected bug fixing.
What Are the Prerequisites for ERP Implementation in SMEs, and What Are Typical Problems?
Prerequisites include a clear business goal (what will improve), designated process owners and key users with dedicated time, and a basic testing methodology and tool. Common problems are lack of resources, immature testing practices, overreliance on the vendor, and treating ERP implementation purely as an IT project - though it affects the entire organization.
In Which Phases Is Testing Most Critical?
Testing is crucial in the planning phase - this determines what and how you will test. Integration testing is the next key phase, proving that modules and interfaces work together, followed by user acceptance testing (UAT) and a full go-live simulation with real processes. Skipping any of these increases go-live risk dramatically.
