Taking over and finishing a Magento 2 store that stalled before launch
We take over unfinished Magento 2 builds left by another supplier. We assess the code, the integrations, the environments and the real scope of the work already done. Then we prepare a plan to close the project and take it to a controlled launch.
We do not assume upfront that the whole store has to be rewritten. First we establish what can safely be reused, what needs fixing and which parts are blocking the launch. On that basis we recommend a takeover, a partial rebuild or a new implementation.
- code and architecture review
- map of gaps and blockers
- integration verification
- QA and code review
- launch preparation
Above, the default template with empty content blocks; below, the same store with finished views and a complete path to purchase.
An unfinished store blocks sales while it keeps consuming time and budget
The hardest part of a takeover is usually not the number of open tasks. The problem is the absence of reliable information about which parts work, what has been accepted and what the launch actually depends on.
An unfinished Magento 2 build blocks planned sales, campaigns and warehouse processes. The client's team spends its time on more meetings, more testing and more discussion of who is responsible, and still has no reliable launch date.
The longer the project stays without an owner, the more of the earlier decisions go out of date. The cost of reimplementing features, updating dependencies and reconstructing knowledge that was never written down keeps rising. If the current platform is not Magento 2, the right starting point is a migration to Magento 2.
- 01
The launch date keeps moving
Every new date depends on work whose scope is still open.
- 02
Features work in isolation, but the full sales path fails testing
The catalogue, the cart, the payment and order handling can each work on their own while the whole process still ends in an error.
- 03
Integrations send some of the data, or only work in one scenario
The problems surface when prices, stock levels, order statuses or customer data change.
- 04
Nobody knows which fixes remove a cause and which mask a symptom
Each new task closes an individual bug without reducing the number of blockers ahead of launch.
- 05
The client's team takes on the role of technical coordinator
The e‑commerce manager ends up personally tracking dependencies between developers, integrators and infrastructure suppliers.
Before a new schedule can be prepared, the finished parts have to be separated from the ones that need work. Only that picture makes it possible to judge whether the Magento 2 project can be completed on its current base.
Let's find what is blocking the launchA takeover makes sense when the project holds a base worth using
Assessing inherited code does not start from the assumption that it will be thrown away. We check which parts can be used, which need fixing, and where further patching would raise the cost without a reasonable justification.
Qualification rests on what can be verified: access to the code and the environments, the ability to test the processes, and whether the business scope is still current. Missing documentation on its own does not rule out a takeover.
The Magento 2 project can be carried on
- a repository exists and the environments are accessible
- some processes are implemented and can be tested
- how the integrations behave can be established
- the business scope of the store is still current
- the main problems can be traced to specific components
- the client can name the people who make decisions and sign work off
A takeover may not be justified
- there is no access to the code, the environments or the configuration
- the architecture does not match the current sales model
- the project relies on unsupported or heavily modified dependencies
- the business scope has changed significantly since the build started
- the cost of repair approaches the cost of an orderly implementation
- the current platform does not match the scale or the processes of the company
Three possible recommendations after the assessment
| Recommendation | What the project looks like | What the scope covers |
|---|---|---|
| Take over the project | The architecture and the integrations match the sales model, and the blockers can be traced to specific pieces of code and configuration. | A plan to close the project, the fixes, QA, code review and launch preparation on the existing base. |
| Partial rebuild | Most of the Magento 2 project is usable, but selected modules, integrations or processes cannot be developed further without putting other areas at risk. | Taking over the sound areas and rewriting the ones the assessment singled out. |
| New implementation | Access is missing, the business scope has changed since the work began, or the cost of repair approaches the cost of an orderly implementation. | Scope agreed on a separate implementation track, using whatever the assessment managed to confirm. |
Take over the project
What the project looks like
The architecture and the integrations match the sales model, and the blockers can be traced to specific pieces of code and configuration.
What the scope covers
A plan to close the project, the fixes, QA, code review and launch preparation on the existing base.
Partial rebuild
What the project looks like
Most of the Magento 2 project is usable, but selected modules, integrations or processes cannot be developed further without putting other areas at risk.
What the scope covers
Taking over the sound areas and rewriting the ones the assessment singled out.
New implementation
What the project looks like
Access is missing, the business scope has changed since the work began, or the cost of repair approaches the cost of an orderly implementation.
What the scope covers
Scope agreed on a separate implementation track, using whatever the assessment managed to confirm.
A recommendation can cover taking over the whole project, keeping selected parts, or starting a defined section again. If the assessment points to a new implementation, the conversation moves to a separate implementation track — for example a D2C implementation for a manufacturer selling directly. The decision should follow from the code and the processes, not from an assumption that everything the previous supplier did is wrong.
Let's check whether the project can be taken overChanging Magento 2 agency mid-build — how does a handover work?
A takeover starts with accesses and code, not with the first line of new development. Below is the order we do it in.
Changing vendor halfway through is a decision often put off for months, because it looks riskier than staying where you are. The risk is real, but it can be contained: the whole first phase is about establishing what actually exists before anyone starts changing it.
- 01
Accesses
Repository, environments (production, staging, local), the Magento admin, server, database, DNS, accounts with external services and payment providers, and access to integration documentation. We send the list at the start — missing some of it does not block the analysis, but it changes its scope.
- 02
Repository handover
We take over the repository with its history, not a copy of a directory from the server. The commit history is often the only record of what was changed and why. If the code exists only in production, the first job is putting it under version control.
- 03
State analysis and backlog
We treat the existing backlog as source material, not as a plan: some items are already done, some are out of date, and some describe problems caused by earlier decisions. The analysis produces a new list in which every item has a confirmed state.
- 04
Integrations
Every connection to an ERP, PIM, WMS, payment provider or carrier is checked separately: whether it works, on whose credentials, who is on the other side, and whether the keys belong to the previous vendor. This is where a takeover most often stalls for weeks.
- 05
Working with the outgoing vendor
If the previous agency is willing to hand over knowledge, we agree a short, specific scope: accesses, a description of the integrations, known problems. If not, the project can be taken over without them — the analysis simply takes longer. We do not build a plan on the assumption that somebody will answer an email.
- 06
The new project plan
It comes after the analysis, not before it. It sets out the work needed to launch, the order, the dependencies and what is deliberately left out of the first release. Development starts once it is approved.
The analysis ends with a map of the work, described below — together with what the cost depends on.
First we establish the facts, then we approve the plan that leads to launch
Six stages, from collecting access to handing over a launched store. Each stage ends in material that stays with the client, even if the engagement goes no further.
A takeover does not start with writing code. It starts with establishing what in the Magento 2 project actually works and which decisions are still valid.
- repository and change history
- staging and production environments
- access to the external systems
- documentation and design decisions
- list of integrations and their owners
- third-party modules and their licences
- backlog, bugs and test scenarios
- deployment procedure and backups
The full takeover checklist runs to several dozen items and we share it at the first call.
- 01
Access and project context
We collect access to the repository, the environments, the external systems, the documentation and the current backlog. We establish which features were meant to be in the first launch and which business decisions still hold.
Resultthe material needed for the assessment, and a list of the access that is missing
- 02
Technical assessment
We review the architecture, the quality of the code, custom modules, third-party extensions, dependencies and how changes are deployed. The assessment also covers environment configuration and anything that could block a stable launch.
Resulta description of what can be taken over, what can be fixed and what has to be replaced
- 03
Verifying features and integrations
We test the key sales processes and the flow of data between Magento 2 and the external systems. We look for the scenarios that end in an error, need manual work, or have no defined owner.
Resulta map of the functional and integration blockers
- 04
The plan to close the project
We order the tasks by dependency, impact on launch and risk. Every item gets acceptance criteria, the assumptions behind it, and a note on which decision or system it depends on.
Resultthe scope needed for launch, the order of work, and an estimate stated together with its assumptions
- 05
Delivery and quality control
A project manager runs the work and the technical tasks go through code review and QA. Each release is tested against the agreed criteria, and anything found goes into an ordered backlog.
Resultone area of the store after another ready to be signed off
- 06
Launch and handover
We prepare the production deployment plan, the scope of post-launch testing and how errors will be handled. After go-live we produce release notes, current documentation and a list of topics for further work.
Resulta launched store and an orderly transition into maintenance
We check the areas that most often stop a Magento 2 launch
Four areas of assessment. Each has a business consequence: it either moves the launch date or creates manual work after go-live.
The assessment is written so that a CTO can judge the technical conclusions while an e‑commerce manager can see the impact on sales and order handling.
Code and architecture
We review custom modules, third-party extensions, overrides, dependencies and how the code is organised. The point is to establish whether further fixes can be made without disturbing other parts of the store.
We also check whether the current version of Magento 2 and the components in use can still be developed safely.
Integrations and data
We verify how the store exchanges data with ERP, PIM, WMS and CRM systems, payment providers, carriers and other services. A single order going through does not confirm that an integration is ready.
Testing covers communication errors, retries, missing data, status changes and the cases that require manual handling.
Sales features
We work through complete user scenarios: catalogue, prices, customer accounts, cart, checkout, payments, delivery and order handling.
For B2B sales the scope can also cover price lists, user roles, limits, commercial terms and the order approval process.
Environments and deployment
We assess how the repository, the staging environment and production are used. We check the configuration, the procedure for publishing changes, the backups, the logs and whether an earlier version can be restored.
Problems in this area are what makes a fix that works on staging behave differently once published. Infrastructure scope is discussed together with maintenance services.
After the assessment you get a map of the work needed before launch
The document puts the Magento 2 project in an order that supports a decision on further funding, priorities and timing. Every recommendation follows from a piece of code, a feature or an integration that was actually checked.
The map does not carry one aggregate number with no explanation. It shows which work is required for launch, which can be deferred, and where the cost depends on the outcome of further verification.
- the confirmed state of the areas already built
- the list of problems blocking launch
- the parts that can be used as they are
- the parts that need fixing or rewriting
- the decisions needed on the client's side
- dependencies between tasks and suppliers
- a proposed order of releases
- acceptance criteria
- risks that affect scope or timing
- the assumptions made while estimating
What does finishing a Magento 2 store cost?
Not what percentage of the project looks done. The cost is driven by how much of the existing work can safely be kept — and that only comes out of the analysis.
What weighs most
- the state of the code: architecture, quality, workarounds and modules changed with no trace in the repository
- the scope of features still missing before sales can start
- the quality of the documentation, from a full specification to none at all
- integrations: how many work, how many need fixing, how many need building again
- the quality of the environments: whether staging exists and whether it matches production
- the scale of fixes left by the previous vendor
- the testing needed before launch
- preparing the production launch: data, redirects, configuration, monitoring
- 01
Take over and continue
The foundation holds: the architecture supports further growth, the code can be maintained, the integrations work or need fixing. We finish the missing scope and take the project to launch. The most common and the cheapest outcome.
- 02
Partial rebuild
Some of the solution is usable and some of it blocks further work — usually the integration layer, the checkout or the frontend. We rebuild those areas and keep the rest. The cost rises, but not by a whole project.
- 03
A new build
Sometimes maintaining the existing code would cost more than building the store again. We say so plainly and show the difference in numbers, rather than finishing something that comes back a year later as the same problem.
The estimate comes after the analysis, because before it it would be guesswork. If the outcome is the third scenario, the right service is often a fixed-scope implementation or a migration to Magento 2, depending on what happens to the current store's data.
It is clear who decides, who builds and who signs off
Roles, decisions and sign-off are described before delivery starts. That limits the situations where a task circulates between the agency, the integrator and the client's team without an owner.
| Role | Scope | Decisions and sign-off |
|---|---|---|
| Project manager | Keeps the backlog, the dependencies and the communication between the client's team and Aurora Creation specialists in order. | Reports how changes affect scope and the order of work. Escalates anything that cannot be settled in the code. |
| Technical team | Assesses the code, the integrations and the architecture, then delivers the agreed scope of work. | Makes technical decisions within the agreed frame. The people building it can discuss the solution directly with the client's CTO or IT team. |
| QA and code review | Checks changes against the agreed acceptance criteria and tests complete sales scenarios. | Holds back a release that does not meet the criteria. Code review limits the risk of carrying problems into other areas of the store. |
| Client's team | Sets priorities and supplies the knowledge about processes that cannot be read out of the code. | Makes the business decisions and signs work off against agreed scenarios, not against a general statement that a feature is done. |
Project manager
Scope
Keeps the backlog, the dependencies and the communication between the client's team and Aurora Creation specialists in order.
Decisions and sign-off
Reports how changes affect scope and the order of work. Escalates anything that cannot be settled in the code.
Technical team
Scope
Assesses the code, the integrations and the architecture, then delivers the agreed scope of work.
Decisions and sign-off
Makes technical decisions within the agreed frame. The people building it can discuss the solution directly with the client's CTO or IT team.
QA and code review
Scope
Checks changes against the agreed acceptance criteria and tests complete sales scenarios.
Decisions and sign-off
Holds back a release that does not meet the criteria. Code review limits the risk of carrying problems into other areas of the store.
Client's team
Scope
Sets priorities and supplies the knowledge about processes that cannot be read out of the code.
Decisions and sign-off
Makes the business decisions and signs work off against agreed scenarios, not against a general statement that a feature is done.
- 01
Business priority
Led by Client's team
- 02
Task analysis
Led by Project manager
- 03
Scope approval
Led by Client's team
- 04
Development
Led by Technical team
- 05
Code review
Led by Technical team
- 06
QA
Led by QA
- 07
Sign-off
Led by Client's team
- 08
Deployment
Led by Project manager
The order is the same for every task, including a fix raised during testing.
This split limits the situations where a problem sits for weeks between the agency, the ERP integrator and the client's team with no clear owner.
Let's talk about how the project would be runSklepBaterie: a taken-over build and catalogue fundamentals put in order
We took the project over mid-way through its migration from CS Store to Magento 2. We put the catalogue architecture, the operational integrations and the Hyvä frontend in order, then prepared the redirects and the launch plan. The store went live with 91% of its existing URLs preserved and 301 redirects covering the rest.
Starting situation: a migration from CS Store to Magento 2 already under way, a catalogue of more than 180,000 items, and no confirmed information about which parts were ready for launch.
Scope of the takeover: catalogue architecture, the Hyvä frontend, the operational integrations, preparing the redirects and the production launch plan.
- 181,000products in the catalogue
- Magento 2target platform
- Hyvästore frontend
A second example
Chrisanne Clover: a build taken over from another agency
The store reached us as an unfinished Magento 2 build started by another vendor. The takeover began with an analysis of its technical state and a remediation plan: we removed errors and redundant features that were weighing the store down, moved it to server infrastructure matched to its size, and implemented category-level access that separated B2B from B2C sales without building a second platform. After the production launch we stayed with the project as technical support under an SLA.
See the Chrisanne Clover case studyA store should enter maintenance with current documentation and an ordered backlog
A launch should not leave the client's team with another list of undocumented dependencies.
The handover covers what was changed, which topics remain open, how the store is configured and what needs further monitoring. The documentation is produced during the work, not after it.
Once the project is finished the store can move into AURORA CARE: maintenance, responding to problems and planned growth of a working Magento 2 platform. If growing sales through an ordered backlog is the priority after launch, the right model is AURORA EVOLUTION.
See AURORA CAREWhat we hand over after launch
- current technical documentation
- a list of open problems
- the post-launch backlog
- a description of who owns each integration
- recommendations for monitoring and infrastructure
Finishing a Magento 2 store: common questions
The questions that come up most often before a decision to take a project over.
Let's discuss the state of your projectYes, and it happens more often than how rarely it is talked about would suggest. What it takes is not the outgoing vendor's consent but access to the code, the environments and the accounts with external services — those belong to the client, not to the agency. The handover is described step by step in the section on changing agency.
The repository with its history, production and staging environments, the Magento admin panel, the server and database, DNS, and accounts with external services: payments, carriers, the ERP and analytics tools. Plus integration documentation, if any exists. Missing some of it does not block a takeover — it changes the scope of the analysis, because whatever cannot be read has to be worked out from the code and the configuration.
It depends above all on the state of the code, the scope of features still missing, the quality of the documentation, how many integrations need fixing, and the scale of testing and launch preparation. The estimate comes after the analysis, because before it it would be guesswork — and that kind of guesswork is usually what brought the project to the state it reaches us in. What weighs most, and the three possible outcomes, are set out in the section on what a takeover costs.
Missing documentation makes the assessment harder but does not rule out a takeover. We will need access to the repository, the environments and the configuration, plus people who know the business processes. The commit history, the Magento configuration and the integration code itself let us reconstruct most of it — the analysis simply takes longer, and one of its outputs is the documentation that was never there.
Yes, and that is usually the first part of the work. The analysis separates the bugs that block launch from those that can be fixed afterwards and those that follow from architectural decisions and cannot be fixed without rebuilding an area. Each group goes into the plan separately, with its cost — so it is visible what is being paid for before launch and what can wait.
Yes, and we say so plainly when that is what the analysis shows. Sometimes maintaining the existing code would cost more than a new build, and we show the difference in numbers rather than finishing something that comes back a year later as the same problem. It is one of the three outcomes the analysis can end with.
Yes, but the order of the work changes. A store that is already selling sets the boundary: first we stabilise what works, only then do we change the rest. The analysis also has to cover the production data — orders, customers and configuration created along the way — because that decides what can be changed without interrupting sales.
No. We assess each area separately. Some of the code can be used unchanged, some needs fixing, and individual parts may qualify for a rewrite. The recommendation follows from the assessment, not from the mere fact that the agency has changed.
We assess the code, the architecture, the modules, the integrations, the environments, how changes are deployed, the documentation and the key sales processes. How deep the assessment goes depends on how far the project has progressed.
Yes, provided both sides have a clear scope and an agreed way of passing information across. That requires access, a current backlog, documentation and named owners for the individual components.
Responsibility depends on the architecture and on the contracts with the system suppliers. During the assessment we establish which part of the flow runs on the Magento 2 side and which on the external system's side. Every blocker gets an owner.
The scope can cover preparing the deployment plan, publishing the changes, post-launch testing and putting the remaining topics in order. The exact split of responsibility is agreed after the assessment.
There is no reliable way to state the time before the code, the integrations and the current scope have been checked. The assessment produces an order of work and an estimate that accounts for the known dependencies and risks.
After go-live the project gets release notes, current documentation and a backlog of further work. Maintenance and growth of the working Magento 2 platform can be taken on under AURORA CARE.
Let's establish what really stands between the project and launch
A first call needs no more than the basics: the current stage, the integrations and the main blockers. After the call we will define which access and material are needed to prepare the assessment.
Have these ready if you can
- a link to the staging version
- the current backlog
- a list of the integrations
- the project documentation
- details of the repository and the environments
- a description of the main problems