Odoo eCommerce and Website implementation

Before any store design work, confirm which Odoo edition and which hosting plan the store will run on, because the answer limits what the website can do and where it can live. Odoo offers a fully open source Community edition and a paid Enterprise edition with additional features and support. Enterprise source code is not publicly available, so using it requires a subscription or partner access. Community code is published on GitHub under LGPL-3.0, which means a team can read and run it, but the eCommerce, payment and Merchant Center features your store depends on may sit on either side of that line. Treat the edition as a product decision, not a deployment detail.

Odoo's pricing page lists three plans: One App Free, Standard and Custom. Per the pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. That combination matters for online stores. A team that wants its own infrastructure, a second company or brand sharing one database, a connection from the storefront to an external order or ERP system through the API, or custom checkout logic must be on Custom and must host on Odoo.sh or on-premise. The One App Free and Standard plans are Odoo Online only. Confirm this against the current pricing page before the design starts, because a store built on the wrong plan may need a re-platforming project later.

Ask Odoo in writing which eCommerce, website, payment provider and Google Merchant Center features are included in each edition and plan, and which need an additional app or subscription. Do not assume that a feature shown in a demo is available on your plan. Pay particular attention to payment provider modules, delivery method integrations, B2B pricing and any Merchant Center connector, since each may be an Enterprise app or a third-party module with its own license. Ask for the answer as a list tied to the app names and version you intend to run, and keep it with the project scope.

Plan the version and support window with the edition decision. Odoo standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, including security updates and bug fixes. Paid extended support afterward is limited to Odoo.sh for select versions and on-premise, and security patches are only provided during standard support. Odoo 17.0 standard support ended in September 2026, so a store launching on it would already be outside standard support. On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years, so the store team should budget for an upgrade cycle as recurring work. Check the support table for the version you choose before you commit.

Finally, document the decision as a short record: edition, plan, hosting location, the list of store features that depend on Custom or Enterprise, and the support end date for the chosen version. Share it with the executive sponsor, finance and whoever will own the store after launch. If the business later needs a second company, a dedicated server in your own data center or a custom API integration, this record shows whether the current plan allows it or whether a plan change is needed. Ask Odoo to confirm any plan change terms in writing.

The store is only as accurate as the data loaded into it, so the first decision is which data sets the store needs and where each one is maintained today. For an Odoo eCommerce and Website build, that means products and their variants, attribute values, sales and B2B price lists, customer records with contact and invoicing details, stock levels per warehouse, product images and the descriptive content that appears on product pages. Most organizations hold these in several places at once: an ERP or accounting system for prices and customer terms, a warehouse system or spreadsheet for stock, a PIM or shared drive for images and copy, and a legacy web shop for anything customers have already bought. Write this inventory down before any file is prepared, because it sets how many sources must be reconciled.

Odoo loads most of this data through its import function, which accepts CSV or Excel files and works from templates for each model, such as products, product variants, attributes, pricelists, customers and inventory adjustments. The template columns and accepted formats change between major versions and between Community and Enterprise, and some related models depend on the Sales, Inventory or Website apps being installed first. Confirm with your implementation lead which import formats, connectors and template versions apply to your exact version and edition before anyone builds a spreadsheet, because a file prepared against the wrong template fails in ways that are hard to diagnose.

Assign one owner to each data set. The person who owns prices should be the one who approves changes to the pricelist, and the owner of stock should be the person who signs off inventory counts. Shared ownership produces duplicate products, conflicting prices and customer records that nobody can account for. Set validation rules before the first load: mandatory fields for each product, unique internal references and barcodes, a defined currency and tax setting per price list, and checks that every variant has a valid attribute combination. Reject or quarantine rows that break these rules rather than correcting them silently in the store, and keep a log of each import run so the owner can trace a changed price to its source file.

Test checks confirm that the store matches the back office. Pick a sample of products across every category, every variant type and every B2B and B2C price list, then compare the price shown on the website, after tax and under the correct customer group, with the figure in the back office. Compare stock quantities for each sellable product against the warehouse count, and check that products with zero or negative available stock are hidden or marked as the business expects. Verify that imported customers can sign in, see their own pricing and reach the right invoicing terms. Repeat the load in a test database first, and record every mismatch, its cause and the owner who fixed it. Plan the checks as a repeatable script, because the same comparisons must run again on the final data before launch.

The handover package is what lets your team run the store without us. It should arrive as a set of documents and exported configuration that match the live system, not a summary written from memory. Ask for the following before go-live is accepted: a configuration record covering pricing lists, tax settings, delivery methods and payment provider settings, with the values in use at handover; product data templates for adding items, variants and attributes; and test scripts for the checkout and order flow, including guest checkout, B2B account pricing, and refunds, so the same tests can be rerun after any change.

Access documentation is the second part. Ask for a list of Odoo user groups and the access rules attached to each, including who can edit prices, publish pages, change payment settings and view customer payment data. Confirm which accounts hold administrator rights, who holds the credentials for payment providers and the Google Merchant Center account, and how those are rotated or removed when staff leave. Where sign-in is federated through LDAP, Google, Microsoft or two-factor authentication, the handover should name the identity source and the fallback administrator account.

The SEO and Merchant Center notes should record how product feeds are generated, which fields are mapped to Merchant Center attributes, the URL and redirect rules used for product pages, and the verification method for each website domain. The runbook covers routine work: adding a product, changing a price across a pricing list, publishing a new variant, and switching a payment provider to test mode and back. Each step should name the screen, the role that performs it and the check that confirms it worked.

Operations after handover depend on how the instance is hosted. On Odoo Online, Odoo operates the platform. On Odoo.sh or on-premise, your team or a partner you contract operates it, and that party owns backups, restores and patch application. Odoo's standard support covers the first three years after a major release, including security updates and bug fixes. Odoo 19.0 is supported until September 2028 and Odoo 18.0 until September 2027. Extended support after that is limited to Odoo.sh for select versions and on-premise, and security patches are only provided during standard support, so check which terms apply to your version.

The upgrade plan should be written at handover, not later. Odoo's documentation states that major version upgrades are mandatory every two years on Odoo Online and Odoo.sh, and the upgrade service moves a database through an upgraded test copy that must be tested before production. Plan a test cycle on that copy, re-run the checkout and order test scripts, and recheck pricing, tax and payment behavior. On-premise upgrades need an Enterprise subscription, and Community users have no access to the upgrade service. Confirm with Odoo which support terms and subscription apply to your plan before setting the upgrade calendar.