An ERP rollout rarely changes just one system — it changes how several departments work at the same time. Whether it succeeds is decided to a large extent by the preparation: unclear processes, an underestimated data migration, forgotten interfaces, or training that only happens right before launch. A company that clarifies the following points before the first request not only gets more realistic offers, it also raises the odds that the rollout actually works once it's live.
Processes first, software second
Before you talk about specific systems, describe the processes that need to be reflected: how does an order flow today from placement to invoice, how does warehouse booking work, how is payroll or project billing handled? Which steps are manual, which run through spreadsheets, which are already digital? A common mistake is to start directly with a system comparison without first critically questioning your own processes — the result is often that an existing, possibly inefficient process simply gets carried over into a new system, instead of using the rollout as an opportunity to simplify it too. So describe not just the current state, but also which weaknesses in the current process are already known.
Plan the data migration
Migrating existing data — customers, items, stock levels, open transactions — is regularly underestimated in planning. Clarify upfront which data from which legacy systems needs to be migrated, what quality it's in today, and who's responsible for cleaning it up before the migration. Faulty or duplicate records don't get corrected by a migration — they simply get carried over into the new system. Also decide whether historical data needs to be fully migrated or whether a cutover date is enough, from which point the new system becomes authoritative. This decision significantly affects the migration effort. If legacy data isn't migrated, tax-relevant data still needs to remain readable for the statutory retention periods (§ 147 AO, GoBD, Germany's tax code and record-keeping rules) — clarify this with your tax advisor.
Interfaces to existing systems
Hardly any ERP system stands alone. Keep a list of the interfaces to other systems that need to be connected — an online shop, time tracking, payroll, a CRM — and which data needs to flow in which direction. If an interface is missing from the list, that often only becomes apparent after launch: a provider can only plan for the interfaces they know about beforehand. Also clarify how the data should flow — through a standardized API, a regular file export, or manual transfer — and whether the connection needs to be close to real time or whether a daily sync is enough. This decision directly affects the technical effort and therefore the price.
Clarify the license and hosting model
Decide whether a cloud/SaaS solution with ongoing license fees is an option, or whether an on-premise installation with your own operations is preferred — both have different consequences for cost, internal maintenance effort, and responsibility for updates. Also ask about the license model itself: per user, per module, or flat-rate, and whether seasonal fluctuations in user count can be accounted for. These questions belong in the request because they affect ongoing costs after the rollout at least as much as the one-time implementation price.
Plan training
New business software only gets used productively if staff actually know how to use it. Plan training time as a fixed part of the project, not an optional add-on at the end. It's worth naming individual people in the affected departments as points of contact ("key users") who get trained in depth and later serve as the first point of call for colleagues. Clarify with the provider whether training materials are made available for later use.
Roll out in phases
An ERP rollout can be implemented either as a full cutover on a single date or in phases, by department or module. A phased approach spreads the risk and lets you learn from an initial phase before further areas follow — but it takes longer overall and often requires running the old and new systems in parallel. A full cutover is completed faster but concentrates the risk on a single point in time. Which approach fits depends on the size of the project and your company's risk appetite — decide on a preference before you request offers.
Test phase before go-live
Before the final cutover, it's worth running a test phase with real but not production-live data: can central workflows — say, a complete order from creation through invoicing — actually be carried out in the new system as expected? Involve the staff who will work with the system daily later on, not just the project leads. Feedback from this phase often reveals gaps that don't show up in the pure concept phase — say, an edge case in order processing that wasn't accounted for in the new process. Allow enough time for this test phase, and decide in advance which feedback needs to be implemented before go-live and which can follow afterward.
Make offers comparable
Summarize processes, data migration, interfaces, license model and timeframe in a scope description — the guide to writing a scope description shows how a complete description is structured. Since ERP offers often mix different pricing models — license costs, implementation effort, training — it's worth looking past the total sum when comparing; the guide to comparing offers explains what to watch for. If the software should instead be built new for you rather than rolled out, the guide to custom software development can help.
Checklist
- Existing processes and their weaknesses documented
- Data migration planned: scope, quality, responsibility for cleanup
- Required interfaces to other systems listed
- License and hosting model (cloud/SaaS vs. on-premise) clarified
- Training time and key users planned
- Rollout phase (full cutover vs. phased) decided
- Test phase with the future users planned before go-live
If you want to move forward with a business-software or ERP rollout, you can describe your project on Projektlotse — with the processes, requirements and timeframe from this guide. Verified IT providers in your region see the request and get in touch with questions and offers. Your company name, exact address and attachments stay confidential until you release them to individual providers. Use is free during the current start phase.