WordPress to Odoo: what changed when we moved our website

For years our website ran on WordPress while everything else ran on Odoo: sales, hiring, projects, invoicing. Five connectors kept the two in agreement, and so did a fair amount of remembering on our part. We recently moved the site into Odoo, and this comes from that migration rather than from a deck.

Our website used to be a separate business. It published pages and collected enquiries on WordPress, while the work those enquiries turned into happened somewhere else entirely.

The arrangement is easy to miss because almost everyone has it. It becomes visible when you count the handoffs. Someone who fills in a form is a lead. Someone who uploads a CV is a candidate. The campaign that brought a person in is the reason a deal exists six months later.

None of that was automatically true while the systems were apart. It was made true by connectors we maintained and by people holding a process in their heads. Moving the website into Odoo is what closed that gap.

Four smaller counts moved with them. Systems to run, patch and staff went from two to one, and so did the specialist skill sets needed to keep the site alive. A campaign page used to need one engineering release and now needs none. A new enquiry used to have two possible locations, the inbox and the pipeline. Now it has one.

The hidden cost of keeping WordPress separate from Odoo

Two systems have to agree, because a company only has one set of facts. Ours agreed through connectors. A connector is a small piece of software whose whole job is to carry a fact from one system to another and hope it arrives.

Five does not sound like much, and that is exactly the problem. Each was cheap to build, and none ever appeared as a line item.

The tax nobody puts on a budget was paid in afternoons of developer time, in campaigns that shipped late, and in the occasional enquiry that sat in an inbox because a connector had quietly stopped working.

The larger cost was structural. Every new form and every new page was an engineering job, so marketing could not change anything without a brief, a developer and a release.

Mostly they did not ask. You cannot count the campaigns nobody proposed.

What improved after moving to Odoo

1. Marketing can launch pages without waiting for engineering

Before, a campaign page was a brief to a developer, a slot in a sprint, a release and a wait. Now marketing duplicates a page that already carries the brand, edits it and publishes it. Nobody is briefed and nothing is released.

The system change is small. The planning change is not.

When a page takes days, you only propose campaigns worth a development cycle, which quietly means the obvious ones. When it takes minutes, marketing can follow an opportunity in the week it exists.

2. Existing AI workflows can work with website content

We already ran AI workflows against Odoo, because that is where the business lives: leads, candidates, quotes, invoices, projects. Those workflows existed long before this migration and had nothing to do with the website.

Reaching website content from them would have meant a separate login, separate skills and another integration to maintain.

Once the site moved into Odoo, that integration stopped being the thing in the way. The workflows did not get smarter and no new tool appeared.

Moving a website is work, so we are not claiming nothing at all was built. We are claiming no AI-to-website integration had to exist, so its maintenance cost never started.

3. Leads and candidates start inside their working pipelines

Before, a website form sent an email and a connector carried a copy into the pipeline when it worked. A new enquiry had two possible locations, and one of them was an inbox. Applications had it worse: around 340 lines of code did nothing but carry a CV from a form into our hiring system.

Now the form is not connected to sales. It is sales. When a visitor presses send, the enquiry exists in the pipeline, owned and timestamped.

An application lands in front of the hiring manager with the CV attached, in the same system where the role, the interview stages and the calendars live.

We are not claiming a measured improvement in response time, because we never measured the old one. What we can say is that an enquiry now has one possible location instead of two, and nobody has to keep a checklist in their head about whether the thing that moves leads is currently moving leads.

4. Marketing gains better continuity and the stack gets simpler

Analytics was never the problem. Google Analytics still covers traffic and behaviour on the site, and we still use it for that.

What we could not do was keep campaign context attached to a person after they stopped being a visitor, because becoming a lead meant crossing into a different system. Now that context travels with the record inside Odoo as it moves through the pipeline. That is not perfect attribution, but it beats a monthly reconciliation between two exports.

We also run one platform to patch, back up, secure, monitor and staff instead of two, and the one we kept is the one we specialise in. Odoo is what we build in for clients every day, so our team maintains our own website with the skills it already has.

That is why this worked for us, and why it will not work for everybody.

The real cost of running the website inside Odoo

One system is one blast radius.

Our marketing site and the software the company runs on now share an upgrade path, a database and a maintenance window. Before, a broken website was embarrassing. Now a bad upgrade can be a bad afternoon for the whole company.

We took that trade deliberately, because the alternative was paying the connector tax forever. It is still a worse position than the one we were in, and we did not solve it. We manage it.

Nothing reaches production without going through a staging copy first, and there is a backup before every upgrade. That converts a risk into a process, which is an improvement only for as long as the process is followed.

The second cost is smaller and constant. Odoo has its own app and module ecosystem, and much of what a marketing site needs is already there or available from third parties. But it is not WordPress's ecosystem, which is broader and deeper for publishing.

Some of what you want will be configuration, some a third-party module and some custom development. For a team publishing thirty pages a month on the back of the WordPress ecosystem, that is a downgrade no integration would compensate for.

When moving your website to Odoo would be a mistake

The case is narrower than the enthusiasm around it suggests. We would not recommend this if:

• You do not already operate deeply inside Odoo. Moving a website into a system nobody really uses does not integrate anything. It relocates a problem and adds a dependency.
• Content publishing is the core business. If you publish constantly, your CMS is a production line rather than a brochure, and a mature publishing ecosystem is worth more than the integration you would gain.
• Nobody in-house or at a trusted partner knows Odoo. Then you are not removing a specialism; you are swapping it for a rarer one, and you have made maintenance harder while telling yourself you simplified it.
• The website is itself the product. An application, marketplace or SaaS platform that happens to have marketing pages is a different situation, and none of this applies.

All four are about your company, not about the software. This decision is almost entirely a question of where your operational centre of gravity already sits.

What surprised us

We spent years getting better at connecting two systems: better retries, better alerting, better error handling. Competent work on a problem we had chosen to keep.

The best integration is the one that stops existing.

That is an uncomfortable lesson, because maintaining an integration feels more justified than making it unnecessary. One has tickets attached to it. The other needs somebody to argue that a thing everyone is used to should not exist.

So here is the question we would put to anyone standing where we stood:

If your website and the system your company actually runs on are separate, what is keeping them in sync costing you?

Most companies cannot answer that, and not because the number is small. It is because the number has never appeared anywhere as a number.

If you are weighing the same move, tell us the part you are stuck on and we will tell you what we would do differently a second time: which parts of this migration were genuinely hard and which were not, what the staging and backup discipline actually costs to keep up, and how this decision looks for a company that is not an Odoo partner. That is the whole exchange.

We run Odoo implementations for a living, so treat that as a disclosure rather than a pitch. A fair number of these conversations end with us saying do not do it.