ERP / Consulting
ERP Version Upgrade
Odoo v14 → v19
Overview
At Portcities, I supported Odoo v14 → v19 upgrade projects across two client engagements. My work sat between testing, issue investigation, documentation and communication — checking migrated functionality, reproducing problems, working with developers and keeping project information organised.
My Role / What I Worked On
Junior ERP Consultant — supporting the project, not leading it.
Test
Checked migrated features module by module — Sales, Accounting, Inventory, Rentals, Repairs — against how they worked before.
Investigate
Reproduced bugs myself before handing them to a developer, so the report was specific rather than vague.
Document
Kept an issue log and a module audit up to date so the team always knew what was open and what was resolved.
Communicate
Wrote updates for developers, the internal team and the client — same issue, different level of detail each time.
A Few Problems I Worked Through
The bug only public visitors could see
Problem
A product page worked fine for me, but a client had reported it breaking for other visitors. I couldn't reproduce it while logged in.
How I investigated it
I worked out that browsing in an incognito window simulates exactly what a public, logged-out visitor sees — and used that to reproduce the error myself instead of guessing at it.
What happened / what I learned
I could now hand the developer a clear, reproducible bug report instead of a secondhand description. It also taught me that "I can't see it" isn't the same as "it isn't happening."
Old files, new system
Problem
After migration, some document links worked fine and others threw server errors on click — with no obvious pattern at first.
How I investigated it
I traced it to files that hadn't been copied across to the new system's storage yet, even though the record of each file had migrated correctly. Because it affected a large share of the catalogue, I flagged that a proper storage transfer at go-live would resolve it on its own.
What happened / what I learned
Rather than manually patching thousands of records, the team held off and let the planned migration step fix it properly. I learned that the right call is sometimes to wait, not to act immediately.
Marked as fixed — but was it?
Problem
A logged issue about duplicate records being created had been marked resolved by a status label alone.
How I investigated it
Instead of accepting the label, I tested the exact scenario myself on the test environment, step by step, to see what actually happened.
What happened / what I learned
The fix genuinely worked, and I could confirm that with confidence — but the habit stuck: I check things myself before signing off, rather than trusting that "done" means done.
The report that wouldn't cooperate
Problem
A Field Service report could no longer be edited properly in Odoo Studio, which was blocking a requested change to the report. The issue involved several inherited QWeb and Studio customisation views layered on top of each other rather than one simple customisation.
How I investigated it
I investigated through Odoo's Technical > Views menu, traced through the relevant inherited views and Studio customisation layers, and inspected the XML. Once I understood the structure, I corrected it and removed the requested report sections, then tested the change in the development environment and confirmed the report printed successfully. Partway through testing, an edit I made in Studio introduced a separate printing issue — I caught it and reverted to the last known-good XML before continuing.
What happened / what I learned
The report printed successfully in the development environment, and the requested changes were ready to progress from there.
Project Artefacts
I can't share the real client documents, so these are recreated from scratch with fictional data, to show the shape of the work rather than the content.
Recreated — fictional dataSample issue log
How a feature moved through testing
(v14)
issues
fix
close
Sample status view
What I Took Away From It
This experience taught me that solving a technology problem isn't always about immediately changing the system. Sometimes the first step is understanding whether something is actually broken, whether behaviour has changed between versions, or whether the issue needs to be explained differently to the user.
I also learned to verify things myself rather than relying only on a status update, and to communicate the same technical issue differently depending on whether I was speaking with a developer, an operations team or a client.
Before building the comments section, I sketched how I thought it should look and work in Figma and showed it to my PM. We went through it, adjusted what needed adjusting, and once it was agreed I implemented it on the front end, then tested and refined it.
The interaction covered writing a comment, choosing a quadrant where relevant, marking it as for or against, an empty state for ideas with no comments yet, and sending or discarding a draft.
No comments yet.