As of: 23 June 2026 · Reading time: 9 min
Key takeaways
- ERP introduction mid-sized businesses: Companies plan selection, processes, data migration and go-live clearly, measurable and with calculable risk.
ERP introduction mid-sized businesses: Companies plan selection, processes, data migration and go-live clearly, measurable and with calculable risk.
“Digitalization is not an IT project—it is a business strategy.”
– Björn Groenewold, Managing Director, Groenewold IT Solutions
If you are looking for an ERP too late, you often pay twice - only with manual workarounds, later with time pressure in the project.
That is why the erp introduction is not a pure IT theme, but an entrepreneurial decision.
It concerns processes, responsibilities, data quality and at the end the question of how planned your operation really is.
Many medium-sized companies only start when the suffering pressure is high: Excel island solutions grow uncontrolled, interfaces are missing, evaluations are unreliable, and each specialist area works with its own logic.
The problem is not only inefficiency. There is also dependence on individuals because knowledge is not in the system, but in minds and secondary processes.
Why ERP integration often fails
Short: Short answer: ERP introduction mid-sized businesses: How companies plan selection, processes, data migration and go-live clearly, measurable and with calculable risk.
Short answer: ERP introduction mid-sized businesses: How companies plan selection, processes, data migration and go-live clearly, measurable and with calculable risk.
Plan correctly for ERP implementation in mid-sized businesses interface & integration projects and system integration are suitable entrances for planning and implementation.
The fewest projects fail on the software alone. In most cases, the cause is earlier - with unclear goals, unclean processes or a selection that is too strongly oriented towards function lists.
If sales, purchasing, production, service and accounting have different expectations, but no one prioritizes, a project with increasing scope and decreasing liability is created.
In addition, there is a classic middle-level error: the ERP should solve everything at the same time.
In addition to the core system, CRM, warehouse logic, release processes, document management, BI and special cases from ten years of history are to be mapped. This is understandable.
It's risky on the project side.
A good ERP introduction reduces complexity rather than transferring it to the new system. This does not mean that requirements are small.
It means to distinguish clean between must, target and later expansion.
ERP Introduction mid-sized businesses: First goals, then software
Short: The crucial question is not: what ERP is the best?
The crucial question is not: what ERP is the best? The better question is: what business-critical processes need to run reliably, transparently and economically in the future?
Three objectives are usually especially relevant for mid-sized businesses. First, continuous processes without media breaks. Secondly, stressful data for decisions. Thirdly, lower operational dependency on individual knowledge.
This results in what system architecture is useful and where standard is enough or individual extensions are necessary. .If you get too early into Tool-Demos, you can narrow the view.
An ERP is not a catalog product that you only unlock. It must fit your business model, your organizational depth and your integration landscape.
A trading company with a high number of variants has different requirements than a project-oriented service provider or a manufacturer with complex production planning.
What questions should be resolved before the selection
Before assessing suppliers, companies should formulate a resilient target image.
This includes which processes in the first phases of the project must necessarily run in the ERP, which old systems are replaced and which systems remain conscious.
Reporting requirements, role models and release logic should also be visible early.
The economic perspective is equally important. Not every requirement justifies individual development.
Conversely, pure standard software is often too rigid when processes are competitively critical or interfaces to machines, portals or third-party systems need to be cleanly integrated.
This is not where ideology decides, but benefits, risk and maintainability.
Clean processes before technology
Many ERP projects are slate because existing processes are taken over unaudited. This leads to old weaknesses being digitized only. Better is a structured view on the actual processes: Where are delays, double data inputs, queries or errors occurring? Which decisions take unnecessarily long? What process steps exist only because the current system has gaps?
At this point it needs technical clarity and moderation. Areas of expertise know the practice. However, the project management has to evaluate what is really relevant.
Otherwise, any exception will be a standard case.
Especially in mid-sized businesses, this is challenging because processes have often grown historically and are strongly influenced by experienced employees.
This is often efficient in day-to-day business, but a risk in ERP project. Because a system needs comprehensible rules, no implicit assumptions.
Standardize where it makes sense
Not every special process is a competitive advantage. Some peculiarities are only the result of previous system boundaries. Who transfers them unfiltered into the new ERP increases effort, complexity and later operating costs.
It is therefore a clear principle: standardize where it simplifies operation. Individualize where it brings measurable business benefits. This separation not only saves budget.
It also creates a system that remains predictable in the long term.
Data Migration is not a secondary topic
Short: In many projects, data migration is taken too late.
In many projects, data migration is taken too late. She decides on the quality of the Go-Live.
Outdated product master files, double debitors, uneven piece lists or unclear history quickly lead to operational problems in the new system.
Therefore, it should be set early which data is migrated, cleaned or deliberately not taken over. Not all old information must be included. Especially in long-grown systems is less often more.
It is crucial that the data in the target system are technically clean, technically consistent and usable for the teams.
Responsibilities must also be clear. IT can technically prepare migrations. However, the technical examination and approval is part of the departments.
Without this assignment, errors often remain undetected until shortly before the start.
Interfaces decide on the real benefits
Short: An ERP does not develop its value isolated.
An ERP does not develop its value isolated. It must work with the system landscape. Depending on the company Shop, CRM, DMS, financial accounting, warehouse technology, time recording, production systems or external platforms.
Exactly here, a theoretically suitable system is often separated from a practically capable system. Missing or poorly planned interfaces later cause manual corrections, delays and data breaks.
Those who consider ERP introduction as a pure software project underestimate these dependencies.
It is therefore important for decision-makers to see interfaces not only as a technical connection, but as part of the business process.
What data will flow when, in what direction and with what liability? Real-time is not always necessary. Consistency and traceability are often more important.
Project organization: Responsibility instead of a side-by-side project
Short: ERP introduction rarely succeeds in addition to the daily business.
ERP introduction rarely succeeds in addition to the daily business. It needs internal responsibility, clear decisions and firm contacts.
When project dates are constantly postponed because key persons are operatively bound, costs and frustration increase on all sides.
A core team of departments, IT and project management with clear decision-making competence has proved successful. A loadable escalation path is also important. Open points must not be in space for weeks.
Otherwise, a standstill occurs in exactly the phases in which liability would be necessary.
An experienced implementation partner introduces structure here - with clean scope, transparent prioritization and realistic milestones.
This is crucial precisely for mid-sized businesses, because resources are limited and projects still have to be managed in a resilient manner.
The Go Live is not the end of the project
Short: Many companies focus so much on the introduction that the phase is underestimated.
Many companies focus so much on the introduction that the phase is underestimated. The real project success is often only shown in operation.
Training, support, monitoring, follow-up and small process corrections are not a sign of poor planning, but part of professional commissioning.
It is important that the Go Live is prepared in a controlled manner. These include test cases from the real daily business, clear cutover plans, defined fallback scenarios and accessible contact persons.
An ERP start without a clean operating transfer quickly generates mistrust in the field - even if the software basically fits.
Especially in the case of business-critical systems, it is not only the introduction that counts, but the ability to secure the ongoing operation in a stable manner.
This is precisely where the difference between a pure implementer and a partner takes responsibility from one hand.
When standard software is enough - and when not
Short: This question is often discussed ideologically.
This question is often discussed ideologically. In practice, it is important. Standard software is economical if processes are largely commercially available and the adjustment depth remains limited.
It often provides a good basis, especially when reporting, roll logic and core sequences can be mapped without great detours.
Individual extensions or tailor-made integrations become relevant if your business model has special processes that cannot be reasonably pressed into the standard.
This concerns about complex release routes, industry-specific calculations, project-oriented accounting logics or the integration of existing systems that are not to be replaced.
For many medium-sized companies, therefore, not the either or question is decisive, but the right combination.
A stable ERP in the core, complemented by clean interfaces and targeted individualization, is often the most economical way.
Groenewold IT Solutions also follows this approach in projects where standard alone is not sufficient and yet planability, GDPR compliance and long-term maintainability are at the forefront.
What decision-makers should realistically check before project start
Short: If you are planning an ERP introduction, you should not only compare budget and provider.
If you are planning an ERP introduction, you should not only compare budget and provider.
Check whether there is sufficient decision-making power internally, how viable your process documentation really is and what old systems cause operational risks.
Equally important is the question whether you can actively conduct a project with many stakeholders or whether you need a partner that controls structure, prioritization and implementation bindingly. .A good decision is not recognized by the fact that all wishes are fulfilled immediately.
It is because the project remains manageable, the benefit is measurable and the system actually works after the go-live instead of being installed.
Those who are seriously concerned with the introduction of ERP in mid-sized businesses should not start with the tool, but with clarity.
Clarity on goals, processes, data, responsibilities and the way to the company. This is where an IT project creates a resilient company building block.
Technical sources and further links
Short: The following independent references complement the classification on the topics of this Article:
The following independent references complement the classification on the topics of this Article:
- Bitkom – Digital Economy Association
- BSI – Federal Office for Information Security
- European Commission – Digital Strategy
- MDN Web Docs (Mozilla)
- W3C – World Wide Web Consortium
"DevOps means less tool sense than common responsibility for quality and rollout – without that, automation remains superficial."
— *Björn Groenewold, Managing Director, Groenewold IT Solutions *
About the author
Managing Director of Groenewold IT Solutions GmbH and Hyperspace GmbH
Since 2009 Björn Groenewold has been developing software solutions for the mid-market. He is Managing Director of Groenewold IT Solutions GmbH (founded 2012) and Hyperspace GmbH. As founder of Groenewold IT Solutions he has successfully supported more than 250 projects – from legacy modernisation to AI integration.
Blog recommendations
Related articles
These posts might also interest you.

Using Public Funding for Business Digitalization
Companies use funding for digitization in a targeted manner - with clear project logic, appropriate programs and less risk in application and implementation.

Calculating App Development Costs Realistically
App development costs depend on scope, interfaces and operation. Companies calculate realistic, transparent and predictable.

Fixed price software project: When it makes sense
A fixed price software project creates planability - if scope, risks and decrease are clear. How companies evaluate when the model fits.
Free download
Checklist: 10 questions before software development
Key points before you start: budget, timeline, and requirements.
Get the checklist in a consultationRelevant next steps
Related services & solutions
Based on this article's topic, these pages are often the most useful next steps.
Related services
Related solutions
Related comparison
More on Legacymodernization and next steps
This article is in the Legacymodernization topic. In our blog overview you will find all articles; under category Legacymodernization more posts on this subject.
For topics like Legacymodernization we offer matching services – from app development and AI integration to legacy modernisation and maintenance. We describe typical use cases under solutions. Our cost calculators give initial estimates. Key terms are in the IT glossary. Books and long-form guides appear on the publications page; deeper articles live under topics.
If you have questions about this article or want a non-binding discussion about your project, you can book a consultation or reach us via contact. We usually respond within one working day.

