Some platform migrations are straightforward. This one wasn’t. Here’s what actually happened when we moved Schweizer Päckli from OctoberCMS to a modern Laravel and Vue 3 stack, and what made it harder than it looked on paper.
Who is Schweizer Päckli and where did we come in?
Schweizer Päckli does something that’s harder to pull off than it sounds: they sell carefully curated packages filled with authentic regional Swiss specialties, and they make the whole thing feel like a genuine gift rather than just another online order.
Each “Päckli” is thoughtfully assembled to bring a piece of a specific Swiss region to the recipient. The contents aren’t generic. They’re selected with real attention to regional provenance, which is what gives the product its character. For someone looking to send something meaningful, that specificity matters.
By mid-2023, the technical foundation holding all of that together had started showing its age. We at what. took on a full platform migration, moving Schweizer Päckli from OctoberCMS to Laravel and Vue 3, with Laravel Nova as the backend. The project wrapped at the beginning of 2024.
Why a full migration made more sense than patching the old system
OctoberCMS had done its job. But the limitations had piled up to the point where working around them was no longer realistic.
Adding new features was nearly impossible. The dependency on CMS plugins meant little control over the underlying data structures. And scaling to new regions, a real strategic goal for Schweizer Päckli, was cumbersome at best.
The honest case for a full migration came down to this: when the architecture itself is the ceiling, incremental improvements just delay the inevitable. Going with Laravel and Vue 3 gave the project a proper foundation:
- Better performance and easier extensibility
- Cleaner data structures with fewer plugin dependencies
- A backend the client could manage independently, without needing to loop in an agency for routine updates
The technical challenges that slowed things down
SSR setup was harder than expected
The most demanding part of the project was configuring Server-Side Rendering (SSR) for the Vue 3 frontend. Because Schweizer Päckli’s shop runs as a Single Page Application (SPA), SSR is what makes it crawlable and indexable by search engines. Without it, the shop effectively doesn’t exist for Google.
The friction came from older JavaScript libraries that assumed a browser environment. The moment you try to render them server-side, they break. The team had to resolve these conflicts one by one.
What made this harder was an additional constraint: the frontend had to look exactly the same as before. The client didn’t want any visible changes to the UI. So the team was rewriting internals while keeping the surface identical, which made what would otherwise be a contained technical problem significantly more delicate.
Data migration and CSS continuity
The existing data had to move cleanly into new schemas without loss or integrity issues. Not the most exciting work, but it’s where migrations often go quietly wrong.
The CSS and SCSS situation was similar. Years of CMS-era stylesheets came with the usual baggage: specificity conflicts, undocumented overrides, styles tied to markup that no longer existed. Getting those to function correctly inside Vue 3 components, without triggering a full visual redesign, took real patience.
What we learned
The invisible work matters most
The most significant outcome nobody noticed was the PDF generation overhaul. Supplier documents look exactly the same as before on the surface. But the internal logic was completely rebuilt to handle a much larger volume of documents than the old system could manage.
It’s a pattern worth internalizing: the improvements that create the most long-term reliability are often the ones users never see. That’s not a reason to skip them. It’s a reason to protect them from being cut.
Modern stack as a prerequisite, not a luxury
On the old platform, almost every new feature request ran into the same wall. The answer was effectively: “we can’t, or it’ll cost a lot.” That’s not just a developer problem. It has direct business consequences.
After the migration, that conversation changed entirely. New regions can now be added from the backend without development work. Features that were previously out of reach are now straightforward to build.
Automated testing protects you when business logic shifts
what. introduced test cases that run before each deployment. For a business like Schweizer Päckli, where the logic around regional packages, suppliers, and orders evolves as the product grows, that’s a genuine safety net. It catches issues early, before they reach customers.
What worked well
A few things landed particularly cleanly:
- CDN setup: Images, JavaScript, and CSS files are now served via CDN across Schweizer Päckli’s multiple regional domains. Assets load faster regardless of which regional version of the site a visitor lands on. A relatively straightforward decision with a disproportionate impact on perceived performance.
- Laravel Nova backend: The client can now manage content, regions, and packages without needing to involve what. for routine updates. That kind of editorial independence reduces dependency on an agency and frees up project time for work that actually requires technical input.
- Region management: Adding a new region, which used to require significant development effort, is now a backend task. There’s also a region switcher that gives an at-a-glance overview of any regional version of the site, useful as the business continues expanding.
What’s still in progress
The migration was the foundation, not the finish line. Schweizer Päckli is actively working on further improvements to the shop, which is exactly the right posture. The new architecture supports that kind of iterative development in a way the old system simply didn’t.
Ongoing topics include shop improvements and further regional expansion. The team isn’t standing still.
Key takeaways from this project
Platform migrations are never purely technical. The hardest constraints on this project were non-technical ones: keeping the UI visually unchanged, migrating years of data cleanly, and working around legacy JavaScript libraries that weren’t built for modern rendering approaches.
The things that created the most durable value weren’t the flashiest deliverables. The PDF overhaul, the CDN setup, the test suite: these are the structural improvements that will quietly prevent problems for years. They’re also the easiest ones to cut when timelines get tight, which is exactly why they shouldn’t be.
If you’re sitting on an aging CMS and finding reasons to delay a migration, the cost of that delay is probably higher than it looks. Every feature request that gets a “we can’t” is a business consequence, not just a technical one.
If you’re thinking about a platform migration or website relaunch, what. helps businesses work through exactly this kind of process, from requirements and system selection through to implementation and go-live. Take a look at what.’s website relaunch and development services to see how we approach it.
