E‑commerce pre-implementation analysis – scope, budget and technology
A pre-implementation analysis puts the sales model, the processes, the data, the integrations and the team's requirements in order before a technology is chosen or an implementation begins. Aurora Creation works with manufacturers and private-label brands that need a credible scope, named risks and a basis for further estimation.
- Requirements
- Processes
- Data and integrations
- Technology
- Risks
- Scope and budget
What is an e‑commerce pre-implementation analysis?
An e‑commerce pre-implementation analysis is the stage that precedes a new build, a migration or a large rebuild of a platform. Its purpose is to gather the business and technical requirements and to prepare the scope, the architecture, the budget and the schedule of the project.
The analysis does not judge the quality of an existing solution — that is what the specialist audits are for. It answers a different question: what has to be built, in what order and at what cost. Which is why its result is a document you can use to approve a scope, choose a technology and start the work.
The more departments, systems and process exceptions bear on sales, the less credible an estimate built from a list of features alone becomes. An analysis turns that list into described processes, named dependencies and decisions taken before development starts.
The analysis prepares
- business and technical requirements
- a scope split into stages
- the architecture of the solution
- a budget estimate
- a delivery schedule
Scope mistakes turn costly once the implementation is under way
An ambiguity found during the analysis usually calls for a conversation and a decision. The same ambiguity found once part of the functionality is built can call for a change to the architecture, to an integration or to a process already in use.
- 01
A list of features with no process behind it
The team collects ideas and requirements, but never settles who performs a given action, where the information comes from and what happens in an exceptional case.
ConsequenceFeatures designed separately start to collide with one another.
- 02
A platform chosen before the requirements are known
The decision follows from earlier experience, from how popular a technology is, or from the first quote that arrived.
ConsequenceSome processes then need expensive modifications or manual workarounds.
- 03
An integration described by the system's name alone
The requirement reads “integration with the ERP”, but names no data, no direction of exchange, no frequency, no exceptions and no process owner.
ConsequenceThe work cannot be quoted honestly, and the blockers surface during implementation.
- 04
Departments hold different priorities
Sales, logistics, marketing, finance and IT each describe the same project from their own perspective.
ConsequenceThe scope grows as the work goes on, because the decisions were never agreed up front.
When a list of features is not enough to settle the scope
A pre-implementation analysis precedes a new build, a migration or a large rebuild of a platform. It is worth running when sales depend on several departments, systems and process exceptions.
See how the analysis runsSituations before an implementation
- 01The company is preparing a new e‑commerce platformIt has to be settled which sales models the first stage should serve, which processes need to change and how the new platform will fit the systems the company already runs.
- 02A migration from an older solution is plannedA migration covers data, URLs, integrations, customer accounts, order history, operational processes and custom features. Some of them have to be moved across, some rebuilt and some deliberately retired.
- 03One platform is to carry both B2C and B2BDifferent user roles, price lists, commercial terms, limits, approvals and order paths have to be described before a shared architecture is designed.
- 04The company is entering further marketsNew domains, languages, currencies, taxes, payments, deliveries and product catalogues all bear on the structure of the platform and on the way its data is managed.
- 05The store will be connected to several systemsERP, PIM, WMS, CRM, marketplaces and marketing tools call for a clear split of responsibility for the data. Without it, the scope of an integration and its error handling are hard to define.
What does a pre-implementation analysis look like, step by step?
The order of the stages is fixed, because each one uses what the previous one settled: a technology cannot be chosen before the processes are known, and a budget cannot be set before the risks are named. How deep each stage goes depends on the project.
- 01
Business goals
We start from the decision the analysis has to prepare and from the sales goals behind the project. We establish which models the platform has to serve: D2C, B2C, B2B, marketplace or selling across several markets. We go through customer roles, pricing rules, revenue channels, the growth plan and the constraints bearing on the first stage.
- 02
Processes and requirements
The people responsible for e‑commerce, sales, logistics, marketing, finance and IT describe how the work is done today and what they expect to change. We look at how the company creates products, prices and promotions, manages stock, fulfils orders, handles complaints and communicates with customers. Anything done by hand or outside the main systems needs particular attention.
- 03
Review of the current environment
We examine the current platform, the environments, the way changes are released, the modifications made so far and the known constraints. This is the stage that shows what can be carried across unchanged, what has to be rebuilt and what is worth retiring deliberately. A detailed review of the code or a test under load is a separate service: a technical audit and a performance audit.
- 04
Required functionality
We turn the requirements into features with a process behind them: who performs the action, where the data comes from and what happens in an exceptional case. We describe the customer journeys — search, registration, purchase, requests for quotation, payment, delivery, returns and after-sales service. B2B projects add permissions, individual price lists, limits, approvals and repeat orders.
- 05
Data and migration
We establish where the source of truth sits for products, prices, customers, stock and orders: the store, the ERP, the PIM, the WMS or the CRM. For a migration project we prepare the plan for moving the data and the systems across — the catalogue, customer accounts, order history, URLs and protecting SEO.
- 06
Integrations
Every integration needs a scope of data, a direction of exchange, a frequency, a process owner and a way of handling errors. A requirement described by the system's name alone cannot be quoted honestly. What the stage leaves behind is a map of the connections between the store, the ERP, the PIM, the WMS, the CRM and the marketplaces.
- 07
Choice of technology
We weigh the requirements and the processes against what the platforms under consideration can do, what they cost to maintain and how much modification each of them would need. The recommendation follows from the earlier stages, not from an assumption made at the start. The technologies we weigh are described further down this page.
- 08
Architecture of the solution
We describe the split of responsibility between the store and the company's systems, the structure of the catalogue and the product data, the handling of several markets and languages, and the non-functional requirements: security, SEO, performance, environments and later maintenance.
- 09
Identifying the risks
We name the external dependencies, the unknowns that call for further checking and the places where the scope could drift: how ready the data is, whether the system vendors have an API available, which processes are handled by hand today. Every risk gets a description of its effect and a way of limiting it.
- 10
Scope, budget and schedule
We close the findings with a scope split into stages, a project backlog, a budget estimate and a delivery schedule. The material also states the decisions that remain with the client and the items that need further checking before they can be quoted.
The form of the final material, the number of meetings, the indicative duration, the make-up of the Aurora Creation team, the way findings are approved and the number of review rounds are written into the offer. To be confirmed before the work starts.
What do you get after a pre-implementation analysis?
The analysis ends with a single piece of material, in the form agreed before the work started. It carries what is needed to approve a scope, compare quotes and start the implementation.
What the closing document carries
- Business requirements
- The project goals, the sales models, the customer roles and the commercial rules the platform has to serve.
- Technical requirements
- The non-functional requirements: security, performance, SEO, environments, the way changes are released and maintenance.
- Functional scope
- Features with a process behind them, split between the first stage and later growth.
- Project backlog
- The scope written out as tasks, in the order the dependencies between them dictate.
- Recommended architecture
- The split of responsibility between the store and the company's systems, the data structure and the handling of several markets.
- Integration map
- The connections to the ERP, the PIM, the WMS, the CRM and the marketplaces, with a direction of exchange, a frequency and a data owner.
- Risk register
- The external dependencies and the unknowns, each with a description of its effect and a way of limiting it.
- Budget estimate
- The cost of the implementation split by stage, along with the items that need to be settled before they can be quoted.
- Delivery schedule
- The order of the stages, their indicative duration and what they depend on in the way of client decisions and materials.
Migration project
For a migration the document also carries the plan for moving the data and the systems across: the scope of the catalogue, customer accounts, order history, URL mapping, the order of the launch and protecting visibility in search.
The scope, the schedule and the estimate from the analysis are the same material the later implementation offer rests on. The document belongs to the client and can be used in a conversation with another supplier too.
Which technologies do we weigh in the analysis?
A pre-implementation analysis is not a service tied to one platform. The comparison starts from the requirements, the processes and the data — the technology is a conclusion of the analysis, not an assumption made before it starts.
The rest of the architecture the analysis covers
- Hyvä
- the front end for Magento 2; bears on the design work and on performance
- ERP
- the source of prices, stock and orders; sets the direction of the integration
- PIM
- managing product data and digital assets
- WMS
- warehouse, picking and shipping
- CRM
- customer data, enquiry handling and sales processes
- System integrations
- the exchange of data between the store, the company's systems and the marketplaces
We run the analysis for the technologies we implement and maintain ourselves. If the requirements point to something outside that range, we say so plainly in the recommendation.
Who should take part in a pre-implementation analysis?
Who joins which meeting depends on the process being discussed. The more departments bear on sales, the more it matters that each of them is heard before the scope is settled — otherwise a missing requirement comes back during the implementation.
On the client's side
- The person responsible for e‑commerce / Product Owner
- Decides the scope and the priorities, and settles differences between departments.
- IT
- Knows the environments, the modifications made so far, the systems and the technical constraints.
- Sales
- Describes the sales models, the price lists, the commercial terms and B2B customer service.
- Marketing
- Brings the requirements around content, promotions, analytics data and visibility.
- Logistics
- Describes order fulfilment, deliveries, returns and how the warehouse works.
- Finance
- States the rules for settlements, documents, payments and reporting.
- The owners of the ERP, the PIM and the other systems
- Answer for the data, for what can be integrated and for the schedule of the work on their side.
On the Aurora Creation side
- Project Manager
- Runs the analysis and keeps the findings, the scope and the dates in order.
- Senior Developer
- Judges whether the requirements are feasible and what the technical choices mean.
- DevOps
- Answers for the environments, releases, performance and security.
- E‑commerce Analyst
- Describes the processes, the data and the integrations, and prepares the closing document.
Not everyone joins every meeting. One person with the authority to decide on the client's side is usually enough, with the process owners invited to the subjects that concern them.
A pre-implementation analysis has a different scope from the specialist audits
A pre-implementation analysis helps establish what has to be built and how far the project should reach. The specialist audits examine one area of a solution that already exists: the technology, the performance, the purchase path or the accessibility.
| Service | Main question | What is examined | When to choose it |
|---|---|---|---|
| Pre-implementation analysis | What should we build, and how do we settle the scope? | The sales model, processes, data, integrations, requirements, priorities and risks | Before a new build, a migration or a large rebuild |
| Technical e‑commerce audit | Can the existing platform be safely developed or taken over? | Code, architecture, modules, integrations, environments, security and technical debt | Before taking a project over, stabilising it or developing an existing solution further |
| E‑commerce performance audit | Where is the platform losing speed and stability? | Response times, front end, back end, database, cache, infrastructure and behaviour under load | When the store is slow or unstable, or cannot cope with growing traffic |
| CRO and CX audit | Where do users abandon the purchase? | Navigation, search, product pages, cart, checkout and the post-purchase experience | When traffic is not turning into the expected level of sales |
| WCAG accessibility audit | Which elements make the site hard to use for people with disabilities? | Interface, content, forms, keyboard navigation, contrast and assistive technologies | When the company wants to check or improve its digital accessibility |
Pre-implementation analysis
What should we build, and how do we settle the scope?
What is examined
The sales model, processes, data, integrations, requirements, priorities and risks
When to choose it
Before a new build, a migration or a large rebuild
Can the existing platform be safely developed or taken over?
What is examined
Code, architecture, modules, integrations, environments, security and technical debt
When to choose it
Before taking a project over, stabilising it or developing an existing solution further
Where is the platform losing speed and stability?
What is examined
Response times, front end, back end, database, cache, infrastructure and behaviour under load
When to choose it
When the store is slow or unstable, or cannot cope with growing traffic
Where do users abandon the purchase?
What is examined
Navigation, search, product pages, cart, checkout and the post-purchase experience
When to choose it
When traffic is not turning into the expected level of sales
Which elements make the site hard to use for people with disabilities?
What is examined
Interface, content, forms, keyboard navigation, contrast and assistive technologies
When to choose it
When the company wants to check or improve its digital accessibility
A pre-implementation analysis in practice – Diablo Chairs
In 2021 Domator24 came to Aurora Creation because their existing site had stopped answering the growing needs of the Diablo Chairs and Jan Nowak brands. Rather than starting the implementation, we agreed together to run a three-month pre-implementation analysis.
The analysis covered the current solution and the brands' existing sites, the business requirements gathered from the teams, the market and the competition, and the future growth plans. It closed with a document setting out in detail the recommended direction for the work that followed. On that basis Domator24 decided, in line with our recommendation, to build a D2C sales platform on Magento 2.
Scope of the analysis
- a review of the current solution and the brands' existing sites
- business requirements gathered from the teams
- an analysis of the market and the competition
- the brand's future growth needs
- a document setting the direction of the project
- three months of analysis before the implementation started
- the move from analysis to a D2C build on Magento 2
FAQ – e‑commerce pre-implementation analysis
The questions companies ask most often when preparing a build, a migration or a move to selling B2C and B2B together.
Let's talk about the analysisWe do not quote a single price, because an analysis is priced by its scope: the number of processes and departments, the number of systems to examine, whether a migration is involved, how many markets are in play and whether the project covers B2C, B2B or both. We confirm the figure and the dates in the offer, after a conversation about the situation and the decision the analysis has to prepare. The factors that move the cost are also collected on the Audit & analysis page.
The duration depends on the number of processes, systems and departments the analysis covers, and on how available the people on the client's side are. We write the indicative duration into the offer before the work starts. On the Diablo Chairs project, an analysis covering two brands, the market, the competition and the growth plans took three months and closed with a document setting out the recommended direction.
On the client's side: the person responsible for e‑commerce or the Product Owner, IT, sales, marketing, logistics, finance, and the owners of the ERP, the PIM and the other systems the project covers. On the Aurora Creation side the analysis involves a Project Manager, a Senior Developer, DevOps and an E‑commerce Analyst. Not everyone joins every meeting — who attends depends on the process being discussed.
A document carrying the business and technical requirements, the functional scope, the project backlog, the recommended architecture, the integration map, the risk register, a budget estimate and a delivery schedule. For a migration project it also carries the plan for moving the data and the systems across. The material belongs to the client and can be used in a conversation with another supplier too.
A migration is one of the projects where an analysis matters most. It has to be settled which data, integrations, custom features and operational processes are carried across unchanged, which are rebuilt and which are deliberately retired, and how visibility in search is protected. The scope of the migration itself is described on the Migration to Magento 2 page.
Yes, and it is one of the more common decisions an analysis prepares. We weigh the requirements and the processes against what each platform can do: how much modification is needed, what maintenance costs, how several markets are handled, what the B2B requirements are and what the integrations demand. Magento 2 usually wins where the operating model is complex, Shopify where the processes can be served by the platform's own features. The recommendation follows from the findings, not from an assumption made before the analysis started.
The person responsible for e‑commerce spends the most time on it, because they join most of the conversations and settle differences between departments. Everyone else is invited to the subjects that concern them — usually a handful of meetings across the whole project, plus the time to share materials and check the findings. We agree the plan of meetings before the work starts.
Yes. The analysis ends with a document that belongs to the client, so it can serve as the basis for a request for quotation and for comparing several suppliers' offers. It does not commit you to building with Aurora Creation.
Yes. For every integration we establish the scope of the data, the direction of exchange, the frequency, the process owner and the way errors are handled, and the result is written down as an integration map. That covers CRM, marketplaces and marketing tools as well. The integration work itself is described on the Pimcore page and among the Magento 2 services.
Yes. The chosen technology does not settle how the processes are served, how far the integrations reach, how the data is migrated or how the project is split into stages. An analysis can also show which requirements will call for heavy customisation. If the choice is Magento 2, the standard features of the platform can be checked beforehand in the Magento 2 demo.
It ends with a budget estimate and a schedule, and those are what the later implementation offer rests on. The final quote depends on how precisely the requirements are stated and on how many unknowns remain — some items may call for a technical audit, a prototype or further information from the system vendors.
Information about the current platform, a list of integrations, a description of the processes, earlier requirements and estimates, details of the markets you are planning and a list of the problems the new project is meant to solve.
It is described as a risk or as a separate subject to check. If it calls for a review of the code, the infrastructure, the performance or the security, the next step can be a technical audit or a performance audit. The other kinds of check are collected on the Audit & analysis page.
Let's start by settling which decision the analysis has to prepare
Describe the stage your project is at, the systems you use and the biggest unknowns. On that basis we'll check whether a pre-implementation analysis is the right starting point, or one of the specialist audits.
Sending the form does not order the service. We come back with the questions needed to judge the right scope for the conversation.
Your first message only needs
- the stage your project is at
- your current platform, or a note that the project starts from scratch
- the sales models
- the most important systems and integrations
- the decision the company wants to prepare
- the planned launch date, if one has been set