Las Vegas Dental Rebuild — Shutdown Deadline, 20 Days
A Las Vegas dental rebuild under a shutdown deadline — 44.2 hours, 20 days. Duplicate metadata corrected, library section scoped out, redirects verified.
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 20-day rebuild under a firm platform-shutdown deadline — the practice’s dental managed-hosting platform was decommissioning on 1 June 2025, with no extension available. We held the 44.2-hour estimate, scoped out the library section per agency instruction, corrected duplicate metadata carried from the legacy platform, and handed off to the agency’s QA window before the shutdown date.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Amazing Smiles Dentistry (Las Vegas, NV) |
| Engagement | White-label WordPress build for a US marketing agency specialising in local-business websites |
| Project Type | WordPress rebuild from a dental managed-hosting platform to WordPress + Elementor Pro on WP Engine |
| Scope | Full site — services, doctor and team pages, library section scoped out, contact forms, meta implementation |
| Timeline | 20 days (30 Apr – 20 May 2025), on schedule with hard external deadline |
| Effort | 44.2 hours on a 44.2-hour estimate — no overrun |
| Team | 4 specialists (dev · QA · content · PM) |
| Tech Stack | WordPress · Elementor Pro · Gravity Forms · WP Engine · Rank Math Pro · 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, scope boundary enforced on library section, 44-hour estimate held |
| Review rounds | ≈3 review rounds across the 20-day calendar window |
The Brief
Amazing Smiles Dentistry was hosted on a dental managed-hosting platform whose service was being discontinued. The agency had a firm date — the platform’s shutdown — and needed the full WordPress rebuild complete and live before that date. No extension was available; if the build overran, the practice would be without a live site.
The agency’s workbook specified every URL to carry over, every redirect, every meta title and description. One structural question required explicit scoping: the legacy platform hosted a /library/ section with dozens of sub-pages on dental education content that were not in the agency’s sitemap. The decision whether to migrate those sub-pages or exclude them belonged to the agency, not to us. We confirmed the scope boundary, excluded the library sub-pages as instructed, and ensured the library section’s incoming links were handled in the redirect map.
The specification also included meta-data accuracy checks: the QA pass identified instances of duplicate H1 text and duplicate meta descriptions that had persisted from the legacy platform. We resolved these against the workbook before handoff.
The stakes on this engagement were sharper than a typical rebuild. Missing a deadline on a project without a fallback platform is not an inconvenience; it is a period of no live presence. The agency needed a team that would hold the estimate, hold the timeline, and not introduce scope drift that would eat into the countdown.
Risk context. The external constraint on this project was categorical: the legacy hosting platform was being shut down on a date the agency could not move. Every hour of overrun narrowed the window for agency QA before go-live. The conventional rebuild risk — a missed redirect eroding rankings — was still present, but secondary. The first-order risk was an overrun that compressed the agency’s sign-off window to the point where the practice went live with unverified work, or did not go live at all. Holding the 44.2-hour estimate precisely was not a quality-of-life feature; it was the condition that made an orderly handoff possible.
How We Did It
1. Template-first build. The full site collapsed into a consistent template set:
- Homepage, About, Contact, and Default fallback
- Services Lander + Service Page template covering the practice’s full treatment catalogue
- Doctor and Team Page templates for practitioner bios
- General content templates for non-service pages
Explicit scope boundary: the legacy platform’s /library/ sub-pages were confirmed out of scope with the agency before development began. Incoming links to that section were handled in the redirect map rather than via page migration.
2. Spec followed line-for-line, from the agency’s sheet. Every target URL, every redirect, every meta title and description came from the workbook. We flagged and corrected the duplicate metadata QA found — identical H1 text across multiple service pages, carried over from the legacy platform’s templating — against the workbook’s per-page specifications before handoff. Where the workbook specified a value, that value landed on the new site.
The principle: the spec is the contract. When the legacy platform has seeded content anomalies into the data (duplicate titles, duplicate descriptions, templated filler text), cleaning them up means reading the workbook more carefully, not improvising corrections.
3. Crawl-based verification, not “looks fine to me”. Before DNS cutover, Screaming Frog ran against both the staging rebuild and the legacy platform. Status codes, redirect chains, meta-tag parity — every delta reconciled against the workbook. We verified the library-section exclusion: no library sub-page paths appeared as live URLs on the new site, and the redirect map covered the section’s main entry point. A second crawl after go-live confirmed internal links resolved on the live domain.
4. Launch checklist, closed before handoff. Design, functionality, content accuracy, SEO and analytics, responsive display, and DNS migration to WP Engine — all closed before handoff. Keeping to the timeline was a direct requirement of the platform-shutdown constraint; the checklist was compressed, not shortened.
Working under the platform-shutdown deadline meant the spec had to be read before a single page was built — the order was not optional. The 44.2-hour estimate held because the redirect map and the metadata corrections were both cleared against the workbook before DNS cutover, leaving the agency a full QA window before the June 1 date.
Results
| Metric | Outcome |
|---|---|
| Spec fidelity — redirects | All agency-specified URLs redirected; library section boundary enforced |
| Spec fidelity — meta data | All meta titles and descriptions placed as specified; duplicate metadata corrected against workbook |
| Spec fidelity — templates | Complete template system built and applied site-wide |
| Scope boundary | Library sub-pages correctly excluded; main library entry point handled in redirect map |
| Timeline | 20 days, delivered on schedule — before platform shutdown date |
| Effort | 44.2h / 44.2h 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 additional content refinements in a retained sprint |
| Site status | Live on WP Engine at https://amazingsmilelv.com/. |
End result: we implemented the agency’s spec as written, inside the quoted hours, before the platform shutdown date. The estimate held; the handoff window was preserved.
Operational Integrity at handoff
Pre-handoff QA caught duplicate meta descriptions carried from the legacy platform across service pages — confirmed manually per page — and a noindex state incorrectly set on Invisalign sub-pages, both resolved against the workbook before the staging build left our hands. Pre-handoff QA ran through Site Checker — see our QA approach for what it checks and why we hold the staging build until every flag is closed. After handoff the agency ran its own checks, raising anything it found in the shared backlog for our fix loop until sign-off.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | 4 days | Agency spec reviewed; library scope boundary confirmed; 44.2h quoted and agreed |
| Development | ~12 days | Full site rebuilt across all templates; library section excluded per spec |
| Internal QA & review | 2 days | Duplicate metadata corrected; all agency-scoped work cleared before handoff |
| Spec verification | 1 day | Meta, redirects, and scope boundary reconciled against workbook |
| Delivery & DNS cutover | 1 day | Site live on WP Engine, no downtime — before platform shutdown date |
Phases overlap (QA ran alongside late development), which is why the calendar timeline is 20 days rather than the sum of individual phases.
Team
Delivery team
- Nikita Tumasevic — lead developer (full site build, template system, and redirect implementation)
- Anna Polunina — development support and estimation
- Evgeniy Karpov — content QA and meta-data corrections
- Pavel Sazhin, xaverPRO — QA and delivery oversight
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
All URL-preservation, redirect-strategy, and scope-boundary decisions belonged to the agency; our role was implementation fidelity to the spec they delivered. Amazing Smiles Dentistry dealt with the agency and the agency alone — our team name never reached the practice, and the rebuild went live under the agency’s account.
For agencies considering a white-label WordPress rebuild
On a dental practice migration with a hard external deadline, the schedule is the governing risk the agency carries. For this practice — a single-location general dentistry group whose new patient intake is tied to local pack visibility. For others — a multi-location DSO-backed provider where the same base content lives under different domains. The redirect map will miss a row, and an old landing page will return 404 instead of passing link equity. The procedure schema will strip out on import, and the rich snippets the agency depends on will vanish. The fixed cutover date will compress the agency QA window until unverified work goes live.
The question to ask a dev partner before committing is not “can you meet the deadline?” — it is “how exactly will you hold the schedule and guarantee the redirect map and schema survive the move?”
Send us a current production URL, a draft redirect map if you have one, or your design files. We will walk the migration spec against your ranking inventory, point to the redirect and schema gaps that will steal your QA window, 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.