What does a Magento 2 implementation look like? The process from choosing an agency to maintenance

Once Magento is installed, you have an e‑commerce platform, not a finished sales system for a particular company.

Magento provides the foundation for the product catalogue, customers, prices, promotions, the cart, orders and CMS content. But you still have to decide how those mechanisms should work in a given business.

Take a manufacturer that sells retail and serves distributors at the same time. The retail price may differ from the B2B partner's price. Product availability may come from the ERP or WMS. Descriptions may come from the PIM. Once an order is placed, its data has to reach the ERP, and Magento should later receive the fulfilment status.

The store is then one of several systems:

That is exactly why the scope of an implementation should not be drawn up merely as a list of screens and features.

For manufacturers there are also D2C sales, B2B, distributors, product catalogues and internal systems to consider. We cover them in more depth in Magento 2 for manufacturers.

First conversations with vendors are far more concrete if the company can answer at least the basic questions:

• who will buy in the store,
• whether sales will cover B2C, B2B, D2C or several models at once,
• how many markets the platform has to serve,
• which systems the company already uses,
• where products, prices and stock levels live,
• what has to be carried over from the old store,
• which processes are unusual,
• which features are needed at the first launch.

This is not about writing your own technical specification before meeting an agency. That is what the analysis is for. The company should, however, know what problem it wants to solve.

“We want Magento” tells a vendor far less than:

“We sell D2C in Poland, within a year we want to enter Germany, we have 40,000 SKUs, the ERP is the source of prices and stock, we keep product data in a PIM and we want to launch a separate path for distributors.”

The second description is enough to start talking about architecture.

With Magento, being able to build online stores is not enough. The more tightly the system is integrated with the company, the more experience with the platform itself, with integrations, migrations and later maintenance matters.

When comparing agencies, we would check a few things above all.

In a simple store some decisions can be made quickly. In a larger project, trying to start development without prior analysis usually means the most important questions come back later, when changes are already more expensive.

Among other things, the analysis has to answer:

• who uses the platform,
• how sales work,
• which processes stay outside Magento,
• where the data sources are,
• which integrations are needed,
• what is to be migrated,
• what must be in the first version,
• what can wait for a later stage.

In more complex projects, a separate e‑commerce pre-implementation analysis lets these decisions be closed before the main work begins.

This is one of the topics that is very easy to overlook.

The company has an ERP, a PIM and Magento. Each of these systems stores information about products. That does not mean each of them should be free to change everything.

An example split might look like this:

Without settling who owns the data, sooner or later someone will ask why the ERP shows one value, the PIM another, and the customer in the store sees a third.

This should be closed before integration work begins.

Once processes and data sources are described, the architecture can be designed.

This is where you settle, among other things:

• the Website, Store and Store View structure,
• markets and languages,
• catalogues,
• currencies,
• price sources,
• how stock is synchronised,
• integrations,
• the frontend,
• search,
• environments,
• infrastructure.

The visual layer matters a great deal, but in a Magento implementation it only comes after many decisions about how the store is meant to work.

The design usually covers, among other things:

• navigation,
• search,
• categories,
• filters,
• the product page,
• the cart,
• checkout,
• the customer account,
• CMS content,
• mobile views.

The frontend can be built in different ways. In new projects one of the available options is Hyvä, an alternative frontend layer for Magento 2.

Not every project needs every page drawn from a blank sheet. If the purchasing process is standard, using a ready component system can shorten the project and leave more of the budget for what is specific to the company.

That is how AURORA ONE, a Magento 2 implementation with a Hyvä frontend in a defined scope, works, among others.

For a project with a non-standard purchase path, an extensive configurator or particular UX requirements, the scope will look different.

Magento code should not be developed directly on the live store.

The project needs a process that lets you create a change, check it before production, and only then release it to customers.

In practice there are development, test or staging environments and production. The exact setup depends on the project.

The code should be versioned in a repository. That way you know which version is on a given environment, who made a change and exactly what went to production.

Adobe's documentation also describes the path from development through Staging to Production (opens in a new tab) and recommends testing a deployment fully before production.

Not every need has to be programmed.

For each requirement, it is worth checking four options first:

1. 01Magento supports it out of the box,
2. 02configuration is enough,
3. 03a sensible extension exists,
4. 04custom development is needed.

Both extremes are expensive.

Writing a feature from scratch that already exists in Magento rarely makes sense. Installing yet another module for every minor requirement can also create a problem.

Every additional extension becomes part of the system, which later has to be updated, tested and checked whenever the Magento version changes.

An integration does not only work when data has passed correctly from system A to system B.

You have to know what happens when something unexpected occurs along the way.

Imagine this case:

1. 01Magento sends an order to the ERP.
2. 02The ERP saves the order.
3. 03The ERP's response is lost on the way.
4. 04Magento does not know the operation succeeded.
5. 05It tries to send the order again.

If the integration cannot recognise that this message has already been handled, a duplicate may appear in the ERP.

So before an integration can be called resilient, you need to check, among other things:

• retries,
• idempotency,
• monitoring,
• timeouts,
• invalid data,
• partial processing,
• how an operation is retried.

Likewise, you have to decide which operations run synchronously and which can go through a queue. A slow ERP should not automatically mean the customer waits a dozen seconds for every page of the store.

Details like these often have more influence on a project's stability than the number of integrations itself.

If Magento replaces an existing platform, migration becomes part of the project.

What may need to move:

• products,
• variants,
• attributes,
• categories,
• customers,
• addresses,
• order history,
• CMS content,
• the blog,
• SEO data,
• URLs.

The first question, however, should be:

Which of this data is still needed?

An old system often holds years of changes, outdated records, duplicated categories, faulty attributes, or workarounds created only because the previous platform had certain limitations.

Migration is a good moment to tidy some of that up.

We describe the whole process of moving data, integrations and URLs in more detail on the page about migrating a store to Magento 2.

At this stage, for the first time, you have to look at the store as a whole rather than as a set of finished tasks.

Opening the home page, a product and checkout is not enough.

You have to walk through real scenarios.

A guest customer places an order. A logged-in customer uses a discount code. A payment is declined. A product goes out of stock. The ERP briefly stops responding. A B2B customer has their own price list. An order has to ship in two parcels.

The areas to test include:

Adobe has separate prelaunch checklists (opens in a new tab), covering production configuration, testing and launch preparation, among other things.

A tester can check whether a discount was applied according to the specification.

But they will not always know that, under the company's internal policy, a particular group of distributors must never be able to combine that discount with a seasonal promotion.

That is why UAT, User Acceptance Testing, is needed before launch.

The client's team then checks the system from the perspective of day-to-day work and real business processes.

It works best when the people doing it are the ones who will actually use the platform later: e‑commerce, sales, warehouse, customer service or marketing.

With an existing store, going live is closer to a migration operation than to publishing a new website.

You have to agree the moment when:

• changes in the old store are frozen,
• the final data migration runs,
• production integrations are switched on,
• DNS is changed,
• test orders are placed,
• payments are checked,
• monitoring starts.

You also need a plan for the situation in which one of the critical elements does not work.

Who decides whether the launch continues? When do we roll back? Who contacts the payment provider? Who checks the ERP?

Adobe's documentation treats the launch phase (opens in a new tab) as a separate stage covering production deployment, security configuration, service verification and performance monitoring.

The store has to run on infrastructure chosen for its characteristics.

What matters includes:

• traffic,
• catalogue size,
• the number of store versions,
• how heavy the imports are,
• the search engine,
• queues,
• integrations,
• availability requirements.

Not every store needs an elaborate cloud architecture. At the same time, hosting picked at random on price alone can become the bottleneck of the whole project.

We describe an example approach to VPS, dedicated servers and AWS on the Magento 2 hosting page.

The first days in production reveal things a test environment cannot always reproduce.

Real customers arrive, with real traffic, the full catalogue, real orders and every external system running at once.

During this period, you watch especially closely:

• application errors,
• checkout,
• payments,
• integrations,
• queues,
• indexes,
• performance,
• server resources.

After launch, some problems will be ordinary bugs to fix. Some will turn out to be a new business need that was not visible before.

And this is where the implementation stage ends and the store's everyday life begins.

A running Magento needs technical care.

Depending on the agreed scope, maintenance may include:

• monitoring,
• responding to outages,
• Magento updates,
• security patches,
• module updates,
• error analysis,
• checking integrations,
• technical administration,
• responding to legal changes that require changes to the store.

The term “Magento support” on its own says little.

The company should know what is monitored, when the team is available and what the procedure is in the event of a critical outage.

At Aurora Creation this area is set apart as AURORA CARE: Magento 2 maintenance, monitoring and an SLA.

An SLA describes how incidents are responded to.

Most often it sets out, among other things:

• hours of availability,
• incident classes,
• response time,
• escalation rules,
• the reporting channel.

A D2C store that sells around the clock needs a different level of protection from a B2B portal that trade partners use mainly on working days.

So an SLA should follow from the business consequences of an outage, not from a wish to have the highest package possible.

The line is fairly simple.

If a checkout that has worked so far starts throwing an error, that is a maintenance problem.

If the company wants to add a new way of placing orders, a feature for its sales reps or a product configurator, that is development.

Development includes, for example:

• a new integration,
• another market,
• rebuilding the product page,
• a new B2B process,
• automating operations,
• extending the customer account.

At Aurora Creation, planned development of existing stores runs under AURORA EVOLUTION, while day-to-day maintenance remains a separate scope.

The split is practical on the client's side too. An order outage has a different priority from marketing's idea for a new product page section.

An agency cannot decide on its own what trade terms a distributor should get. The client, in turn, should not be forced to design the integration architecture.

The split of responsibilities might look like this, for example:

Most problems tend to arise where responsibility was left “by default”.

There is no single timeline for a Magento implementation.

A project with a ready scope and few dependencies can go live relatively quickly. A B2B platform connected to an ERP, PIM and WMS, with a large catalogue migration and several markets, is a different undertaking altogether.

The timeline depends above all on:

• custom features,
• the number of integrations,
• API readiness,
• data quality,
• the scope of migration,
• the number of markets,
• the UX/UI process,
• testing,
• the time the client needs for decisions.

That is why the question “how long does Magento take?” does not help much.

A far better one is:

How long will this particular scope take, and which dependencies does the deadline hinge on?

The question of price works the same way.

The cost of a project may include:

• analysis,
• UX/UI design,
• frontend,
• configuration,
• development,
• modules,
• integrations,
• migration,
• testing,
• infrastructure,
• maintenance.

Two proposals can differ by tens of percent and both still be reasonable, if they cover a different scope.

That is exactly why, when comparing proposals, you have to go one level below the total at the bottom of the document.

Imagine two proposals.

The first contains a single line:

ERP integration: PLN 15,000.

In the second, the scope is broken down into products, prices, stock, orders, trade partners, statuses, the queue, retries and monitoring.

We do not yet have grounds to say which proposal is more expensive.

First you have to check whether both really cover the same thing.

For every larger element of the project, it should be possible to answer three questions:

• What exactly will be done?
• What is out of scope?
• How will we know the task is finished?

That is a much better way to compare proposals than lining up hourly rates.

Changing agency mid-project does not automatically mean everything has to be written again from the start.

First you have to check what actually exists.

In a takeover we look at, among other things:

• the code,
• the repository,
• the configuration,
• the environments,
• modules,
• integrations,
• infrastructure,
• data,
• documentation,
• open tasks.

Only after a review like this can you decide which elements to keep, which to fix and whether anything has to be redone.

Aurora Creation runs such projects as a separate scope: completing a Magento 2 store someone else started.

A well-prepared project does not end with the client receiving a store and its login details.

The company should know:

• where the code lives,
• what the architecture looks like,
• which systems are the source of data,
• how changes are deployed,
• where production runs,
• who is responsible for the infrastructure,
• who monitors the store,
• who responds to outages,
• how updates are carried out,
• how development requests are raised.

That is why, at Aurora Creation, these needs are kept apart.

New projects can be delivered as AURORA ONE or as custom Magento implementations, among other options. A running store can move under AURORA CARE, and new development work goes to AURORA EVOLUTION.

Implementation, maintenance and development concern the same platform, but they solve different problems.

And that is the moment you can call the implementation finished.

Not the day Magento was installed.