Dental SaaS-to-WordPress Rebuild, 33 Hours Delivered
Dental SaaS-to-WordPress migration from Officite to Elementor Pro — 33 hours across 18 days, legacy paths redirected, privacy policy converted from PDF.
Screenshots captured by automated tooling — some elements may not have loaded fully or may layer on top of each other. For the most accurate view, visit the live site →
Rebuild the site on a new stack. Implement the spec. Don't improvise. Hand it back ready for cutover.
Client (end user): Rappaport Dental
Engagement: White-label development for a US marketing agency
Delivered: May 2025 · 18 days · 33 hours development · on schedule, no overrun
The Craft of a Rebuild
A dental practice migrating from an Officite SaaS platform to WordPress + Elementor Pro — the legacy platform generated auto-published article paths invisible to standard sitemaps, and the privacy policy existed only as a hosted PDF. Across 18 days and 33 development hours, we audited the legacy URL surface for hidden paths, converted the privacy policy to a navigable page, and shipped the rebuild to the agency’s spec with no overrun.
This case study is a record of one such rebuild, in which the agency owned the strategy and we owned the execution.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Rappaport Dental |
| Engagement | White-label WordPress build for a US marketing agency specialising in local-business websites |
| Project Type | WordPress rebuild from a dental-industry SaaS platform to WordPress + Elementor Pro on WP Engine |
| Scope | Full site — services, about, contact, privacy policy (converted from PDF), redirect cleanup of SaaS-generated URL paths |
| Timeline | 18 days (9 May – 26 May 2025), on schedule |
| Effort | 33 hours development against a 33-hour estimate — no overrun |
| Team | 5 specialists (dev · QA · content fixes · PM) |
| Tech Stack | WordPress · Elementor Pro · Gravity Forms · WP Engine · Yoast · Screaming Frog · Site Checker (xaverPRO QA plugin) |
| Content parity check | Original-vs-rebuild content diff cleared before handoff — no missing copy, no broken internal links, no structural drift |
| Delivered | Spec followed line-for-line — redirects, meta titles, privacy policy page, SaaS-path cleanup, launch checklist |
| Review rounds | ≈5 review rounds across the 18-day calendar window |
| Per-ticket effort | 7 internal Redmine tickets · median 10h / P75 10h per ticket |
The Brief
Rappaport Dental was running its web presence on a proprietary dental-industry SaaS platform — managed hosting with a built-in dental content system. The agency needed the site moved to a standard WordPress stack for greater editorial control and long-term SEO manageability. Unlike a CMS-to-CMS rebuild, migrating from a dental SaaS platform to WordPress is a one-way transition: the old platform’s URL conventions, content structures, and auto-generated paths don’t map cleanly onto WordPress slugs.
The agency’s workbook carried every target URL, every meta title and description, every template assignment, and the redirect strategy for legacy paths. They also needed a specific content conversion: the practice’s privacy policy had existed only as a hosted PDF on the old platform and needed to be rebuilt as a proper WordPress page before go-live.
All decisions about which legacy URLs to preserve, redirect, or retire belonged to the agency. Our role was implementation fidelity to their delivered spec.
The risk the agency was managing was not a generic redirect-map risk. It was the specific shape of a dental SaaS migration — a platform that generates structured paths for article libraries, category archives, and specialty content sections that have no WordPress equivalent. If any of those auto-generated paths were in the index and the redirect spec didn’t cover them, the agency’s crawl would surface a gap. The discipline was treating the SaaS platform’s URL surface as adversarial rather than simple: assuming paths existed that wouldn’t appear in a standard sitemap export.
Risk context. Dental-industry SaaS platforms like the one Rappaport Dental was migrating from generate URL structures that a standard sitemap review does not capture — article archive paths, category slugs, and provider-generated content sections can accumulate in index without appearing in the agency’s sitemap column. The failure mode at cutover is not a broken homepage; it is a crawl-discovered cluster of 4xx paths that nobody’s spec anticipated. Handling this rebuild correctly required actively auditing the legacy platform’s URL surface for auto-generated paths, surfacing them to the agency before cutover, and confirming whether they were in-scope for redirection or out-of-scope for retirement.
How We Did It
1. Template-first build. The full site collapsed into a consistent template set applied across every content type:
- Homepage, About, Contact, and Default fallback
- Services Lander + Service Page template covering the practice’s full treatment catalogue
- Privacy Policy page — converted from the legacy platform’s hosted PDF into a proper WordPress page with navigable content
- Blog and general content templates
Templates covered every content type in the workbook. Future edits live in one place per page type.
2. Spec followed line-for-line, from the agency’s sheet. The Google Sheets workbook carried every target URL with its redirect mapping from legacy paths, every meta title and description, every template assignment. We implemented each row as written. Where the workbook defined a redirect, we implemented it. Where a legacy SaaS-generated path was explicitly scoped out — such as old article archive paths the agency had reviewed and decided not to redirect — we confirmed the retirement decision rather than guessing.
The principle: on a rebuild, the spec is the agency’s commitment to the client. Our job is not to reinterpret it; it is to execute it without deviation.
3. Crawl-based verification, not “looks fine to me”. Before DNS cutover, Screaming Frog ran against both the staging rebuild and the legacy SaaS platform simultaneously. Status codes, redirect chains, meta-tag differences, and any paths found in the legacy crawl but absent from the agency’s spec — all reconciled before cutover. Privacy policy page content was compared against the source PDF to confirm fidelity. A second crawl after go-live confirmed internal links resolved on the live domain.
4. Launch checklist, closed before handoff. Design fidelity, form functionality, content accuracy, SEO and analytics, responsive display, and a DNS migration sequence to WP Engine — all closed before handoff. Cross-device QA on Chrome, Firefox, Safari, and Edge at multiple viewport widths.
The constraint of auditing the SaaS platform’s URL surface before touching the build meant the redirect spec came first. An article-archive path with no content — not in the agency’s sitemap, not in their spec — surfaced during that audit; we confirmed retirement scope with the agency before cutting over. The dev work followed from a validated surface, not from a sitemap we assumed was complete.
Results
| Metric | Outcome |
|---|---|
| Spec fidelity — redirects | All agency-specified legacy paths redirected; auto-generated SaaS paths outside spec confirmed retired |
| Spec fidelity — meta data | All meta titles and descriptions placed as specified |
| Spec fidelity — templates | Complete template system built and applied site-wide |
| Spec fidelity — privacy policy | Legacy PDF converted to a navigable WordPress page |
| Timeline | 18 days, delivered on schedule |
| Effort | 33h / 33h development estimate — no overrun, no scope creep |
| Responsive verification | Zero layout issues across 4 browsers × 6 viewports |
| Internal QA | All agency-scoped issues closed before handoff; post-launch agency QA round addressed content and link refinements in a retained sprint |
| Handoff | Site live on WP Engine on the scheduled cutover day, no downtime |
| Site status | rappdental.com live in production |
The outcome, restated plainly: the agency’s migration spec was implemented as written, on the scheduled cutover day, with the legacy SaaS platform’s URL surface fully audited against the spec before handoff.
Operational Integrity at handoff
During pre-handoff QA, Site Checker’s URL structure check surfaced a legacy SaaS article-archive path (/articles/dear_doctor/category/47365) with an unusual slug and no content — precisely the class of auto-generated path the brief warned would not appear in a standard sitemap export — and a concurrent QA pass confirmed redirects were not yet live on staging; both were resolved before handoff. Pre-handoff QA ran through Site Checker — see our QA discipline for the categories and the fail-zero gate. The agency’s own QA layer — their tools, their process — ran post-handoff and surfaced issues into the shared backlog for our fix loop until they signed off.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | 3 days | Agency spec reviewed; SaaS URL surface audited; 33h development quoted and agreed |
| Development | ~10 days | Full site rebuilt; privacy policy page converted from PDF; redirect map implemented |
| Internal QA & review | 3 days | Issues logged; legacy SaaS path audit completed; all agency-scoped work cleared |
| Spec verification | 1 day | Meta, redirects, and page content reconciled against workbook |
| Delivery & DNS cutover | 1 day | Site live on WP Engine, no downtime |
Phases overlap (QA ran alongside late development), which is why the calendar timeline is 18 days rather than the sum of individual phases.
Team
Delivery team
- Nikita Tumasevic — lead developer (full site build, template system, and redirect implementation)
- Pavel Sazhin, xaverPRO — QA and delivery oversight
- Anna Polunina — implementation support and QA across the rebuilt pages
- Evgeniy Karpov — content and QA fix rounds
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
All URL-preservation and redirect-strategy decisions belonged to the agency; our role was implementation fidelity to the spec they delivered. The agency remained the visible vendor; we were invisible to the end client throughout.
For agencies considering a white-label WordPress build
If your agency is moving a client off a dental-industry SaaS platform — Officite, DoctorsInternet, or similar — send the legacy platform’s URL export alongside your redirect spec. We will audit the auto-generated path surface against the spec before estimating, surface any paths the spec hasn’t covered, and return a fixed-hours quote within 24 hours. No cost. No obligation to proceed.
Don't have a spec yet? Send a one-paragraph description — we'll come back with the questions worth asking. Send a description →
Site Checker runs before the agency sees anything.
Before handoff, every staging build runs through Site Checker — the WordPress QA plugin we built and maintain. It is a fail-zero gate: nothing goes to the agency with an open failure. Warnings are reviewed and judged non-blocking; the agency gets a clean slate to run their own QA layer against, not a staging site with known issues in the queue.