Website Page Migration
by Odoo DevHouse https://apps.odoo.com/apps/modules/browse?author=Odoo%20DevHouse$ 175.00
Website Page Migration
Pull website pages, blog posts, menus and product descriptions straight from another Odoo database into this one - over XML-RPC, no SSH, no direct DB access, no copy/paste.
Moving from a staging database to production, consolidating two Odoo instances after an acquisition, or migrating off an old Odoo Online database - every one of these forces the same painful choice: give someone direct database/SSH access they shouldn't have, or re-type every page, blog post and menu by hand and hope the SEO metadata survives the trip.
- No safe way to pull content from a database you don't have server access to
- Copy/pasting page HTML by hand breaks inline images and loses SEO metadata
- Re-running the same migration duplicates pages instead of updating them
- No audit trail of what migrated cleanly and what needs a manual look
- Product page descriptions get typed twice - once in the old shop, once in the new one
Register the remote Odoo database's URL, database name, a login and an API key, test the connection, then create a Migration Job and pick what to bring over - website pages, blog posts, menus, and product descriptions matched by Internal Reference. The job talks to the source over standard XML-RPC (the same API-key mechanism Odoo's own external API uses), re-uploads inline images so pages don't stay dependent on the old server, carries over SEO metadata and translations, and logs every record it touched - success, skipped, or error - so nothing migrates silently wrong. Run it once by hand, or tick "Run Automatically" and let the daily cron keep pulling in new and changed content, safely, since re-running a job updates previously migrated records instead of duplicating them.
- XML-RPC Only: connects with a URL, database, username and API key - no SSH, no direct Postgres access, no exported files to shuttle around
- Four Content Types: website pages, blog posts (with their blogs and tags), website menus (parent/child hierarchy preserved), and product page descriptions matched to existing products by Internal Reference
- Domain Filters: per content type, so a job can pull "just the pages under /about" or "only published blog posts" instead of everything
- SEO Preserved: meta title, meta description, meta keywords and social share image copy over with the content, not left behind
- Multi-language: every language installed on both databases gets its own translated copy of the migrated content, not just the default language
- Images Re-uploaded: inline images referenced in migrated HTML are downloaded and re-uploaded as local attachments, with their URLs rewritten - pages don't stay dependent on the old server staying online
- Idempotent Re-runs: a remote/local record mapping means running the same job twice updates existing records instead of creating duplicates - safe to schedule daily
- Preview Before You Commit: Preview Migration runs the real logic and discards every change - see predicted creates, updates, skips and removals with nothing actually touched
- Protects Local Edits: a record changed locally after the last sync is skipped instead of silently overwritten - turn it off if you want the remote to always win
- Stays in Sync With Deletions: a page or post removed on the source gets unpublished locally on the next run, instead of living online forever
- 301 Redirects on URL Changes: when a page's URL changes on the source, the local URL updates too and a redirect from the old path keeps links and rankings intact
- Scales to Large Sites: remote content is fetched in batches, not one unbounded request, so a site with thousands of pages migrates without timing out
- Per-record Audit Log: every page, post, menu and product gets its own log line - Success, Skipped, or Error, with the reason - so a partial migration is visible, not silent
- Automatic Retry: transient network errors on either the XML-RPC calls or the image downloads are retried with exponential backoff before being logged as a failure
- Scheduled Jobs: tick "Run Automatically" on a job and a daily scheduled action keeps it in sync, no manual re-runs needed
Register the Remote Instance
Go to Website -> Configuration -> Website Migration -> Remote Instances and add the source database's URL, database name, username and an API key (generated the same way as Odoo's own external API). Click Test Connection - it authenticates over XML-RPC and reports the remote server version before anything is migrated.
Create a Migration Job
Under Migration Jobs, pick the remote instance, the destination website, and tick which content types to bring over - Website Pages, Website Menus, Blog Posts, Product Descriptions. Optionally narrow pages/posts/products down with a domain filter, and choose whether inline images should be re-uploaded locally.
Run It - Once or on a Schedule
Click Run Migration Now to migrate immediately, or tick Run Automatically Every Day and activate the module's scheduled action so the job keeps pulling in new and changed content on its own - re-running never creates duplicates, it just updates what's already there.
Review the Log
Every job keeps a per-record log - open it from the Log Entries smart button. Each page, post, menu and product shows as Success, Skipped (e.g. no local product matched that Internal Reference) or Error, with the reason, so you know exactly what needs a manual look before publishing.
Every screenshot below is from an actual run: a seeded Odoo 18.0 database with custom pages, a blog and products as the source; this module installed on a fresh Odoo 19.0 database as the destination, connected over real XML-RPC - configure, connect, preview, run, review, and the live result on the frontend.
Step 1 - Remote Instance, Connected
Test Connection against the Odoo 18 source authenticates over XML-RPC, reports the real remote server version and uid, and flips the ribbon to Connected.
Step 2 - Configure the Job
Pick the content types to migrate and the safety toggles: sync page URLs and create redirects, protect local edits, and unpublish content removed on the source - each one explained inline, each one on by default.
Step 3 - Preview Before Touching Anything
Preview Migration runs the exact same logic a real migration would - then discards every change. The banner makes it unmistakable: 26 predicted records, nothing created, updated, or removed yet.
Step 4 - Run It For Real
Run Migration Now - same 26 records, this time actually created. The preview banner is gone; the counts are real.
Step 5 - Per-record Migration Log
Every page, menu, blog post and product gets its own row - model, record name, the remote ID it came from, whether it was a preview or a real write, and a Success/Skipped/ Error badge. Nothing migrates silently.
Step 6 - A Migrated Page, Live on the Odoo 19 Site
This "About Us" page - heading, paragraphs and inline image - was written once on the Odoo 18 source and never touched by hand on the destination. The image itself was downloaded from the source and re-uploaded as a local attachment.
Step 7 - Any Custom Page, Not Just the Obvious Ones
This "Our Team" page was never anything special on the source - a plain custom page with a bullet list. It migrated exactly like every other page, no special-casing required.
Step 8 - Blog Post With Tags and the Whole Blog Intact
The blog, its tags, and the post content all came across - along with the "next post" teaser, which only works because the whole blog was migrated, not just one entry.
Step 9 - Product Description, Matched by Internal Reference
This product already existed on the destination (its Internal Reference is what made the match) - only its eCommerce description and website description were migrated onto it, exactly as designed: never a new product, just the content.
On the source, "Our Services" was deleted and "Our Team" was renamed to /meet-the-team, while the destination's "About Us" page was hand-edited locally. The job was then re-run - not staged, not mocked, the real second run against the real content.
Step 10 - Skipped and Removed, Side by Side in the Log
The re-run's log shows it plainly: the hand-edited "About Us" content and the renamed "Our Team" menu come back Skipped with the exact protection message, while "Our Services" - deleted on the source - comes back Success with "Removed locally: no longer exists on the remote source." One log, both safety features, no silent overwrites.
Step 11 - A Real 301 Redirect, Created Automatically
Renaming the page's URL on the source to /meet-the-team didn't just update the local page - it created this website.rewrite record, redirecting /our-team to /meet-the-team with a real 301, so nothing that already links to the old URL breaks.
Step 12 - The Hand Edit Survived the Re-run
Proof on the live frontend: the heading was manually changed to "About Migration Demo Co. (Hand-Edited Locally)" after the first migration, then the job was run again. The edit is still here - protect_local_edits skipped the page instead of overwriting it.
Like any content migration tool, a handful of things stay manual: dynamic blocks (product listings, blog feeds) may render empty until re-configured, and theme/styling settings are intentionally not touched so your destination site's look and feel is left alone.
A migration tool that only ever adds content isn't safe to run twice. These four controls exist because a real, repeated sync also has to handle edits, deletions, and renames without surprising anyone - each one is a toggle on the job, on by default.
Runs the exact same logic a real migration would - same lookups, same protection checks, same deletion detection - inside a database savepoint that always rolls back. Nothing is created, updated, or removed; only the predicted log entries (clearly tagged "Preview") are kept, so you see the outcome before committing to it.
If someone edits a migrated page locally after the last sync, the next run skips it instead of clobbering their changes - logged clearly as Skipped, with the reason. Turn the toggle off on a job if you'd rather the remote content always wins.
A page or blog post deleted on the source gets unpublished locally on the next run instead of staying live forever - checked by id, ignoring any domain filter, so a page merely excluded from a narrower filter is never mistaken for one that's gone. Menus are removed outright since they have no unpublished state. Never applies to products - migration doesn't own their lifecycle, only their descriptions.
When a page's URL changes on the source, the local URL updates to match and a 301 redirect from the old path is created automatically - so bookmarks, inbound links and search rankings keep working. Never steals a URL already used by a different local page, and guards against redirect loops from a page renamed back and forth.
A migration you can only safely run once isn't a migration tool, it's a one-off script. Every design choice here is about making a job safe to schedule and forget.
The source database just needs its standard XML-RPC endpoint reachable and an API key for the login
used - Odoo Online, Odoo.sh, and on-premise instances all expose it the same way. This module installs
into Odoo 19.0 and depends on website, website_blog and
website_sale.
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Website (website)
• eCommerce (website_sale) • Discuss (mail) • Invoicing (account) |
| Lines of code | 1097 |
| Technical Name |
website_page_migration |
| License | OPL-1 |
| Website | https://apps.odoo.com/apps/modules/browse?author=Odoo%20DevHouse |
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module