The short version
I’m a Python developer who specialises in Odoo, and for the last few years most of my work has been the same problem: moving databases between Odoo versions without losing data, breaking custom code, or stopping the business.
That’s what this site is about now. Not because migrations are all I do — but because they’re the part companies can’t afford to get wrong, and the part that gets put off for years.
What a migration means here
“Migration” covers three different jobs:
- Version upgrades — taking a live database to a newer Odoo, custom code and data included.
- Leaving a legacy system — moving years of history from an old ERP into Odoo, verified.
- Rescue missions — a stalled upgrade, a migration that “worked” but left broken records, an installation too fragile to touch.
All three follow the same rule: staging first, production last, and nothing is assumed. Record counts, checks and reports get compared before anyone switches over.
What I work with
- Python and the Odoo framework: models, the ORM, controllers, wizards, reports, migration scripts
- Odoo upgrade tooling: the official upgrade service for Enterprise, OCA’s OpenUpgrade for Community
- PostgreSQL: schema design, indexing, reading query plans, tuning config for real workloads
- Redis: caching and sessions when Odoo needs the help
- JavaScript, OWL and Vue.js: custom views and widgets, plus the odd standalone frontend
- REST APIs: building them on top of Odoo and consuming everyone else’s
How I work
- Questions first. Most bad migrations come from not knowing what’s actually in the database. That’s what the assessment is for.
- Staging is sacred. Your production database is never the first one to meet an upgrade.
- Verified, then live. The data checks happen before cutover, not after.
- You’ll always know where things stand. Regular updates, early warnings when something is harder than expected, and no disappearing for two weeks.
- I leave things documented. Your team (or the next developer) should be able to understand what changed without calling me.
A few numbers
- Top-Rated Plus on Upwork
- 100% Job Success across 50+ delivered projects
- 6+ years working on Odoo
- 5 TB — the largest single database I’ve migrated, for a manufacturer running 500+ users
How I got here
I started out writing general Python. Odoo came along on a client project, and I liked that it gave me a real framework to build business software on instead of starting from scratch every time. One Odoo project led to the next, and at some point it stopped being a side skill and became the job.
The migration specialism happened the same way. Upgrades were the jobs nobody wanted to quote for — risky, fiddly, hard to scope. Doing them properly, over and over, turned out to be a skill worth having. Since then I’ve worked with manufacturers, online shops, logistics companies, service businesses and a few others. The industries are different, but the problems keep rhyming: data lives in three places, a process that made sense at 10 users falls apart at 200, and an upgrade got put off for so long that it now feels dangerous.
Most of my job is turning “this is how we actually work” into something Odoo can keep running — across versions, not just today.
Industries I’ve worked in
- Manufacturing and production
- E-commerce and retail
- Professional services
- Logistics and supply chain
- Healthcare
- Education and training
Typical engagements
- Odoo version upgrades (13 → 18, Community and Enterprise)
- Migrating from legacy ERPs and in-house systems into Odoo
- Rescue missions for failed or stalled migrations
- Custom module development and porting
- Data verification and reconciliation after a move
- Performance audits and PostgreSQL tuning
Working together
If you’re planning a migration, stuck in one, or know it’s coming and want to understand what it takes — send me a message. Tell me what you’re running and what worries you, and I’ll tell you honestly whether I can help.