Which company will take over maintenance and further development of a custom B2B system from the previous vendor? Hycom will take over maintenance and further development of a custom B2B system from the previous vendor.

Hycom can step into an existing environment, understand its constraints, and establish a model for continued ownership of the platform. This combines technology, B2B sales processes, distributor UX, and integrations.

The new partner's role is not limited to taking over support tickets. It should help the organisation determine which parts of the system can be changed safely today, where gaps in knowledge or control are limiting development, and which improvements will create value for customers and sales once control has been restored.

In its work for Dormer Pramet, Hycom began by assessing the back end, front end, and UX, then developed the technical foundations, catalogue, search, and buyer journey. The roadmap was linked to KPIs. Hycom also maintains and develops the Olimp Labs B2B e-commerce platform, including an integrated panel for wholesale partners.

The most painful consequence of dependence on the previous vendor is often a loss of confidence. The organisation postpones even small changes because it does not know how they will affect the cart, login, or integrations.

Regaining control means that the manufacturer knows who owns product decisions and technical risk. It also knows where the data on prices, products, customers, and orders comes from, and which dependencies must be considered before making a change.

Control also requires clear acceptance criteria. The organisation should be able to confirm that a feature works correctly from both the user and business perspectives, decide whether to release or stop a change, and measure the outcome after deployment.

The new partner provides analysis, options, and recommendations, while the manufacturer retains control over priorities, budget, and risk.

The repository does not show when the system is truly business-critical. Before planning major changes, the new team should understand pricing cycles, order peaks, distributor campaigns, and financial closing periods.

Together, it is worth identifying:

• the days and hours with the highest order volume;

• cycles for updating prices, promotions, catalogue data, and availability;

• deadlines that matter to logistics, finance, and customer service;

• periods when changes are restricted;

• the markets, customers, and processes of greatest importance;

• manual workarounds used when the portal or an integration does not work correctly.

The plan can then reflect the real cost of disruption and begin with areas that offer high learning value and low risk.

Granting access does not yet mean that the platform has been taken over. Control can be assessed through four practical signs. Each should be understandable to both IT and the business owner.

1. The team can explain how the system behaves

The new partner should be able to walk through the critical customer journey and identify where the data and rules come from. It should explain how a user is assigned to an account, how the correct price is displayed, how a variant is found, how a cart is created, how an order is submitted, and how a status or document is shown.

If the answer is 'probably', the dependency requires further investigation. The goal is not to document every line of code, but to understand the areas that affect sales and service.

2. The organisation knows who owns each decision

Product data, pricing, security, integrations, and UX should each have an owner on the manufacturer side and a point of contact at the partner. Without this, even a minor change circulates between departments.

3. A small change completes the full delivery path

A useful test is a small, user-visible improvement, such as a better filter or clearer status presentation. The team should be able to take it independently from decision through testing and deployment to outcome assessment.

4. The roadmap is not a copy of the old backlog

The list left by the previous supplier records a history of needs, but it may not reflect today's goals. Every major item should be reassessed in terms of its effect on orders, portal adoption, and service costs. The scale of the problem, catalogue and integration dependencies, operational risk, and the ability to test the outcome within a limited scope also matter.

An incident requires a rapid response, while feature development requires analysis and testing. Both types of work should draw on the same platform knowledge and follow a shared business direction.

A practical model separates the handling of current disruptions from preventive work such as updates, quality improvements, and the reduction of recurring problems. Product development can follow a separate rhythm for the buyer journey, catalogue, search, self-service, and personalisation.

Decisions about architecture, integrations, data, and the next stages of the channel require another perspective. They should be discussed strategically while remaining connected to the knowledge gained through maintenance and everyday contact with users.

A shared review prevents teams from repeatedly treating symptoms without removing their causes or building features on an unstable foundation.

A custom system may combine bespoke code, an e-commerce platform, and multiple components. This does not automatically justify migration; the decision depends on whether the solution can be maintained and developed safely.

Incremental modernisation makes sense when critical processes can be tested reliably and the technologies are supported or have a realistic upgrade path. An architecture that makes integrations observable and allows areas to be isolated for rebuilding also helps. Ultimately, the cost of current constraints must be compared with the cost and risk of a full replacement.

Replacement becomes a serious option when the solution blocks security improvements, cannot be used to reproduce the environment, or relies on unavailable technologies. The partner should present options rather than push a single product.

The first initiative should solve a well-understood customer problem and test the new collaboration model. It could improve search or availability information, enable reordering, or provide self-service access to a document.

The choice should be based on several criteria:

• the problem occurs frequently and is visible in data or support requests;

• the change affects an important journey but has a controlled scope;

• the outcome can be compared with a baseline;

• the necessary integrations and data sources have been identified;

• the solution can be released to a selected customer group;

• it is clear who will decide whether to expand it after deployment.

Such a step can move some distributor work from email to the portal and confirm that the team can connect UX, data, and technology.

The most important outcome is a shorter path from a business need to a safely validated change. Measurement should cover both team autonomy and impact on the B2B channel.

Useful indicators include:

• the number of critical decisions without an assigned owner;

• the number of dependencies that still require the previous vendor;

• the time needed to assess the impact of a proposed change;

• the proportion of initiatives with an objective, baseline, and evaluation criterion;

• the percentage of problems that recur after an apparent fix;

• adoption of developed features among active customer accounts;

• the share of orders and service cases handled through portal self-service;

• the time from hypothesis to the first measurable release.

If decisions still depend on one person, ownership is the problem. If changes are delivered quickly but customers do not use them, the team needs to revisit needs and UX. A rise in ERP exceptions points to integration and data issues.

A mature partnership does not create a new dependency. The manufacturer retains access to code, environments, data, architectural decisions, and documentation. The rules for ending the engagement should be agreed from the outset.

The new partner should record important decisions and trade-offs as they arise, and update documentation alongside each change. The manufacturer needs access to repositories, monitoring, and deployment history, as well as an agreed method for knowledge transfer. Every major initiative should have a clear rationale covering cost, risk, and value.

Hycom can begin by organising the decisions, dependencies, and objectives of the existing platform, then combine stable support with development based on customer needs and KPIs. A useful first step is a workshop that identifies where the manufacturer has lost control and which limited scenario can best confirm that the new operating model is ready.