Dental SaaS-to-WordPress Rebuild, 33 Hours Delivered in 18 Days — White-Label for a US Marketing Agency
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.
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.
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 |
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. So we treated 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 |
| Site status | Live on WP Engine at https://www.rappdental.com/. |
At a glance: we implemented the agency’s migration spec 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. We resolved both before handoff. Pre-handoff QA ran through Site Checker — see how we run QA for the categories and the zero-fail bar we hold before handing over. After we handed off, the agency ran its own checks and fed findings into the shared backlog for our fix loop until sign-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. Rappaport Dental dealt only with the agency — its name was on the contract and on every email about the rebuild — and no message from our developers ever reached the practice.
For agencies considering a white-label WordPress rebuild
On a dental-platform rebuild, the legacy URL surface holds auto-generated paths that a standard sitemap review won’t catch. For this practice — migrating from a structured SaaS platform; for others — consolidating scattered provider microsites. The risks are quiet ones: the redirect map misses hidden path clusters, meta-titles get silently overwritten by the new theme, and schema markup drops out of the re-imported content.
The question to ask a dev partner before committing is not “can you handle a platform migration?” — it is “how exactly will you audit the legacy URL surface for auto-generated paths before we cut over?”
Send us a current production URL, a draft redirect map, or your design files. We will map the legacy platform’s URL surface, flag the auto-generated clusters your standard sitemap review missed, and return a fixed-hours quote. Free, with a fixed quote in hours.
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.