Changing your store and ERP: together or in stages?

If the existing ERP reliably supports orders, purchasing and stock management while the storefront holds back sales, PrestaShop can be the first step. The team initially retains familiar operational processes while the new customer-facing experience can be tested specifically.

The cost may include a temporary connection to the old ERP. If that system is due to be replaced a few months later, the proposal must make this work visible. We would identify which parts of the integration can be reused and which exist only for the transition. Without that distinction, the first phase can appear cheaper than the complete project actually is.

If product identifiers, pricing rules or order handling are unresolved, a new storefront will not fix them. It may then make sense to stabilise the ERP and working processes first. The existing store remains in use temporarily and must be able to work with the new ERP.

This approach also needs a viable interim solution. If connecting the old store is impractical, its apparent advantage disappears. Where Odoo is the intended ERP, we examine the period before the future PrestaShop launch as well as the final setup. The sequence should suit the business, rather than the preferred software of one participant.

A combined replacement can be appropriate when both old systems must be retired and a temporary integration would require disproportionate effort. However, it concentrates risk: new data, interfaces and working processes reach the team at the same time.

Both parts of the project therefore need dependable results before launch. If only the store is ready, a calendar deadline will not complete the ERP implementation. We would adjust the scope or date. A joint launch is a deliberate option, not a shortcut around missing coordination.

We would discuss six points with the store team and those responsible for the ERP:

• Trigger: Which existing system causes the problem that needs to be solved first?
• Dependencies: Which data structure or decision must be settled before the next step?
• Interim operation: Can the old store work with the new ERP, or the new store with the old ERP?
• Effort: What will temporary integrations, repeated testing and later changes cost?
• Capacity: Which employees are needed for training, data checks and acceptance testing?
• Approval: What demonstrable result allows the next project phase to begin?

Our approach combines task lists with checks of real workflows. We examine the storefront, orders and shipping; the merchant contributes the specific back-office routines used by their team. This tests the planned sequence where day-to-day operations will ultimately need to work.

Consider a planning example: a merchant has a stable ERP, but customers struggle to find important product variants in the old store. We would first examine the sales process and a potential PrestaShop rebuild. If ERP replacement comes later, the temporary integration needs a clearly limited scope.

In a second illustrative scenario, prices and product assignments are already inconsistent in the ERP. A more modern store would inherit those inconsistencies. The first task is therefore more likely to concern data and the ERP. These examples illustrate decisions; they are not presented as completed client projects.

Our published Brennerei Höllberg reference demonstrates another useful point: when migrating from Shopware 5 to PrestaShop 8, we retained the familiar appearance and introduced targeted improvements. A platform change does not have to change every layer at once. This reference does not establish that an ERP replacement took place or reveal any ERP migration sequence.

We document the target setup, the interim state and the prerequisites for each transition. Temporary costs belong alongside ongoing maintenance. PrestaShop is our preferred option to evaluate when the buying experience and individual features need focused development. The necessary customisation and integrations remain part of the project.

The result is a reasoned sequence rather than a blanket decision to replace everything. The actual cutover during ongoing operations and migration of data and module content are separate next steps. To discuss your PrestaShop rebuild, it helps us to know the current systems, their retirement deadlines and the three workflows that must remain reliable throughout the transition.