Case study
We Upgraded a Live Odoo System From 17 to 19 and Shipped a New Storefront in the Same Release
An in-place upgrade of Wells & Drew's live Odoo database, with a written runbook, two full rehearsals on a copy of live data, a rollback plan, and a new storefront and client portal going out with it.
- Client
- Wells & Drew
- Platform
- Odoo
- Services
- Odoo
- Timeframe
- wellsdrew.com (opens in a new tab) · June to October 2026
Results
37 steps
Runbook
With five go/no-go gates and a written rollback plan
2
Full rehearsals
Odoo.sh test upgrades on a copy of live data
19 min
Final rehearsal, platform upgrade
Plus 4.5 minutes of build, on October 11, 2026
27
Live-system changes carried over
Commits made on Odoo 17 during the project, each checked before go-live
Oct 11, 2026
Go-live
In-place upgrade of the live database
Operational improvements
The platform is on a current Odoo version, with the former Studio customizations in code. The upgrade path itself is now written down: the runbook, the gates and the rollback plan can be reused for the next version.
Business impact
Wells & Drew moved to Odoo 19 and got a new storefront and client portal in one release, on the live database, with every order and setting kept where it was.
01 · The situation
What was going on before we started.
What was breaking
Odoo 17 was falling behind, and every month on it added custom work that would have to be ported later. Some customizations lived in Studio and some behavior lived in scripts loaded from another server, outside the code.
What was at risk
An upgrade that builds cleanly can still lose fields, views and outside behavior without any error. On a live order system, that shows up as orders that will not confirm or pages that stop working, in front of customers.
The business
Wells & Drew is a family-owned specialty printer in Jacksonville, Florida, in continuous operation since 1855. Professional firms order business cards, letterhead and other stationery through their own client stores on its Odoo platform.
Existing stack
Odoo 17 on Odoo.sh. Custom modules from Parameter, a quotation engine from a prior vendor, a third-party ShipStation connector, a purchased storefront theme, and screens customized in Odoo Studio.
Scale
One Odoo database on Odoo.sh serving two companies and two websites, with 319 installed modules, 44 of them custom (October 2026).
Constraints
The live system had to keep taking orders throughout, and it kept changing: work for the business did not stop for the upgrade. Two websites share the one database, so every step had to be right for both. The release also carried a new storefront and a rebuilt portal, not just the version change.
02 · Approach & solution
The decisions behind the build.
Why this approach
Upgrade the live database in place, after rehearsing on copies of it. That keeps every order, customer and setting where it is, and the rehearsals show what the upgrade will do before it is done for real.
Alternatives considered
Building a fresh Odoo 19 database and migrating data into it was the other route. It means re-creating years of records and settings, which is a bigger risk than upgrading the database that already holds them.
Tradeoffs
In-place upgrades need careful rehearsal, a frozen live system during the cutover, and a tested way back. In return nothing has to be re-created.
Constraints
Everything had to be ready to go back: a tagged copy of the old code and fresh database backups before the push. Customer-facing pages showed a maintenance page during the cutover.
03 · Workstreams
Five pieces of work, in order.
Port and prepare
What was done
Updated every custom module for Odoo 19. The first full test upgrade passed on staging on June 28, 2026. Studio screens were moved into code, and custom views the upgrade platform switched off were set to switch back on automatically after the update.
Why it mattered
Customizations outside the code are the first thing an upgrade loses.
What it replaced
Customizations held in Odoo Studio
Keep up with the live system
What was done
Tracked every change made on the live Odoo 17 system after the upgrade branch was created: 27 commits. Eighteen needed porting, four were already ported, three needed a check at runtime, and two were not needed.
Why it mattered
A live business does not stop changing for an upgrade. Anything not carried over would have been lost at go-live.
Write the cutover plan
What was done
A written plan, reviewed twice: a decisions log, a 37-step runbook with five go/no-go gates, and a rollback plan with a tagged copy of the old code and database backups taken before the push.
Why it mattered
Go-live day is the wrong day to decide what to do when something fails.
Rehearse twice
What was done
Ran the full upgrade twice on a copy of live data using Odoo.sh's test upgrade. The final rehearsal on October 11 passed, with a 19-minute platform upgrade and a 4.5-minute build.
Why it mattered
A rehearsal on real data finds what tests on sample data miss, and it tells you how long the real cutover will take.
Go live and follow through
What was done
Upgraded the live database in place on October 11, 2026, with both websites on a maintenance page during the cutover. The new storefront, the rebuilt client portal and the rebuilt designers went live with it. 130 commits followed in the first days, fixes and client requests together.
Why it mattered
Go-live is not the end of an upgrade. The first days decide whether people trust the new system.
What it replaced
Odoo 17
04 · Execution
The stack and the decisions behind it.
- Odoo 17 and Odoo 19 on Odoo.sh
- Odoo.sh test upgrade (rehearsals on a copy of live data)
- Custom modules in a Git repository
- Written cutover plan: decisions log, 37-step runbook, rollback plan
Technical decisions
The tools and why they were chosen
An in-place upgrade of the live database, not a fresh database with migrated data. Every custom module's version set for Odoo 19, because a module still marked for 17 is left out. Studio customizations moved into code before the upgrade. Views the upgrade platform switched off are switched back on by code after the update instead of by hand.
Turning points
The moments that shaped the outcome
Shipping the storefront and portal on Odoo 19 instead of building them on 17 first. It made the release bigger, but nothing had to be built twice.
Unexpected issues
The surprises were the kind a build cannot show
The surprises were the kind a build cannot show. Stale website-builder copies of pages had to be archived before the storefront worked. A copied quotation report still used a removed field and blocked order confirmation until it was fixed. Three days after go-live, the office address prefill in the business-card designer was found missing and restored.
The full story
The project start to finish, in one read
Most Odoo upgrades are described as a version jump. This one was a release. Between June and October 2026, Parameter moved Wells & Drew’s live Odoo platform from version 17 to 19 and shipped, in the same release, the new storefront, client stores and card designers described in the Wells & Drew case study.
Work began on June 26, 2026. Two days later the first full test upgrade, with every custom module updated for Odoo 19, passed on staging. That was the easy part. The hard part was everything a green build does not show: fields and views Odoo drops without warning, customizations made in Studio, behavior loaded from scripts on another server, and the live system itself, which kept changing while the upgrade was built.
The answer was a written cutover plan, reviewed twice: a decisions log, a 37-step runbook with five go/no-go gates, and a rollback plan with a tagged copy of the old code and database backups taken before the push. Studio screens were moved into code before go-live, and custom views the upgrade platform switched off were switched back on automatically after the update.
The upgrade was rehearsed twice on a copy of live data using Odoo.sh’s test upgrade. The final rehearsal, on October 11, passed: the platform upgrade took 19 minutes and the build 4.5 minutes. The same day, the live database was upgraded in place.
The first days after go-live were real work. 130 commits followed in the first days, fixes and client requests together. One example: three days in, the office address prefill in the business-card designer turned out to be missing, and it was restored.
05 · Takeaways
What carries over to other projects.
Who this applies to
Businesses running a customized Odoo system that takes orders every day, especially with Studio changes, website pages edited in the builder, or behavior loaded from outside scripts.
Patterns observed
A green upgrade build is the start of testing, not the end. The live system keeps changing during the project, so the list of what to carry over has to be kept until the last day. And the first days after go-live need people ready to fix things fast.
When to consider this
When your Odoo version is two releases behind. When your setup has Studio changes, builder-edited pages or outside scripts. When an upgrade has to happen on a system that cannot stop taking orders.
Next step
Want this kind of clarity on your own stack?
If your site, store, or business system is carrying silent risk, we can map the problem, choose the right approach, and turn it into something steadier.