Case study: moving BüroService Direkt from old WordPress to a secure customer platform

A website eventually stops being just a website. For BüroService Direkt, the old WordPress presence had grown over many years: service pages, news, contact routes and a historic web-dictation context were sitting next to each other. For a business that works with law firms, confidential dictations and administrative support, that was no longer enough.

The relaunch was therefore not a design-only project. It was a full technical and editorial rebuild: away from an outdated, hard-to-control WordPress system and toward a maintainable platform with clear information architecture, protected customer access, repeatable deployments and room for future extensions.

Starting point

BüroService Direkt is an owner-led office service provider in Berlin. Its services include secretarial support, preparatory bookkeeping, writing and proofreading, legal office support and web dictation for law firms and businesses. That breadth was no longer easy to understand on the old site.

Several typical problems of a grown WordPress setup came together:

• unclear structure between services, audiences and news
• outdated technical foundation with security and maintenance risk
• wording that no longer focused consistently on search intent and customer value
• a digital service requirement beyond a classic brochure website
• missing CI and deployment guarantees for repeatable changes

The task was not to make the old system look nicer. The task was to turn the website back into a controlled business and service channel.

Why continuing with plugins was not the right move

A WordPress relaunch can be the right decision when editing workflows, theme, plugin set and hosting are still healthy. In this case, another cleanup would only have delayed the real problem. The risk was not just visual. It was the combination of legacy code, broad attack surface and limited operational control.

The new system was built around a slimmer architecture:

• Next.js as the public frontend
• PocketBase for protected customer and web-dictation data
• MDX for editorial news content
• clear public routes for services, law firms, contact, references, jobs and required legal pages
• server-side actions for contact, account, service-request and dictation workflows
• GitHub Actions as the mandatory build and deploy path
• PM2, Caddy, Doppler and an unprivileged VPS deploy user in production

The result is not a heavy platform. It is a deliberately narrow website and customer-portal architecture where each critical function follows a clear path.

Wording and information architecture

The relaunch turned the old collection of services into a clearer structure. Visitors can now understand faster whether they need writing support, web dictation, bookkeeping, secretarial work or law-firm relief.

One important decision was to separate general services from audience-specific pages. The law-firm page is not a duplicate of legal secretarial support. It explains the wider operational pressure of a law firm: dictations, pleadings, correspondence, proofreading, workflows and temporary bottlenecks. The legal-secretarial detail page stays closer to the specific service.

The homepage was not treated as generic marketing space either. It now leads with benefit, audience, process and contact paths. The copy moved away from “we offer everything” and toward “which concrete problem gets solved reliably?”

Customer portal and web dictation

The most important difference from a pure marketing site is the protected customer area. Customers can create web dictations, upload audio files, provide document type, recipient, subject, notes and attachments, and review their history.

Several security and reliability decisions support this flow:

• sessions are protected through encrypted server-side cookies
• PocketBase tokens are not stored in a readable browser cookie
• suspended accounts lose access to existing sessions
• password and email changes can invalidate existing sessions
• customer files are not linked directly from public URLs
• media downloads go through authenticated application routes with range support, private cache headers and nosniff protection
• audio uploads, attachments and processing paths have size and abuse controls

This matters especially for dictation. An audio file is not just an upload. It may contain legal, personal, medical or business information. A modern-looking form is not enough; the access path itself has to be correct.

Contact forms and abuse control

The public contact path was treated as an operational risk as well. It combines signed form tokens, a honeypot, minimum form age, link and content checks, and server-side rate limiting. The rate limit runs before database writes and before outbound email.

That distinction matters. Many websites protect only the visible form. In practice, the expensive path is what needs protection: database growth, SMTP volume, inbox noise and mail-provider reputation.

CI, deployment and operations

A relaunch is only stable when changes can be shipped repeatedly. For BüroService Direkt, the deployment path was made explicit:

• GitHub Actions installs dependencies, runs lint and build, and creates a release artifact.
• The artifact is uploaded to the VPS over SSH.
• Deployments do not use root; they run through a dedicated unprivileged deploy user.
• PM2 runs the web app and PocketBase under that user.
• Doppler provides production configuration without committing secrets.
• PocketBase migrations run explicitly during deployment.
• Releases are versioned under a shared app directory and can be rolled back.

This changes the operating model from “the website is online” to a controlled release process. Navigation, content, sessions, uploads and migrations all move through the same repeatable path.

SEO, structure and discoverability

The new site contains more than new copy. It also exposes technical signals that search engines and AI search systems can interpret:

• canonical metadata per page
• Open Graph and Twitter metadata
• LocalBusiness and ProfessionalService JSON-LD
• Service and FAQ JSON-LD on relevant service pages
• sitemap entries for public pages and news articles
• robots rules that exclude private areas
• redirects from old WordPress service URLs to the new Next.js routes

Old signals were not left behind. They were mapped into the new structure. At the same time, private areas such as dashboard, login and password flows are not part of the public sitemap.

Result

The relaunch moved BüroService Direkt from an outdated WordPress presence to a controlled technical platform. The visible changes are the modernized website, clearer service pages, a stronger law-firm focus, a new news structure and an integrated customer portal.

The less visible changes are more important:

• less dependency on plugins and themes
• clear CI and build checks
• versioned deployments
• safer customer-data paths
• better control over sessions, uploads and email delivery
• structured SEO foundation for existing and future content
• an architecture that can grow without recreating the old legacy problem

What other website owners can learn

Not every old WordPress site needs a full rebuild. But when a site is outdated, security-sensitive, unclear in its content and hard to operate, a cosmetic relaunch is not enough.

The key question is not: which new design looks better? The better question is: which technical and organizational paths need to become controllable?

For BüroService Direkt, those paths were customer access, web dictation, file access, contact forms, search structure and deployment. Only after those paths were rebuilt did the relaunch become a durable technical restart.