Service Agreement

1. Discovery and scope confirmation

WPReborn reviews the purchased tier against the actual website, integrations and migration requirements. Material mismatches are clarified before out-of-scope work begins. A fixed package remains subject to the boundaries displayed on the package and any written clarifications accepted for the project.

2. Source access and migration inputs

The customer provides authorized access, source files, exports, DNS or hosting coordination and other inputs reasonably required for delivery. Passwords and other sensitive access details should not be sent through public forms. WPReborn will arrange an appropriate handover method when access is required.

3. Build and parity

The rebuild targets the agreed visual experience and functionality without reproducing unnecessary WordPress runtime dependencies. Where functionality depends on WordPress-only plugins or proprietary third-party services, WPReborn may reproduce the required behavior, integrate an alternative, or identify it as a scoped exception.

4. URL, content and commerce continuity

Where included in scope, existing routes are inventoried and mapped so redirects, canonical behavior and user-facing navigation can be preserved. E-commerce migrations additionally require catalog, checkout, payment and transactional workflow verification according to the package or custom scope.

The process is designed to preserve operational progress, but search rankings, payment-provider behavior and third-party platform outcomes remain subject to systems WPReborn does not control.

5. Verification and cutover

WPReborn performs agreed functional checks before cutover. The customer may be asked to confirm business-critical journeys or content. DNS changes, provider propagation, caching and third-party systems can create timing outside WPReborn control, so cutover planning may include a defined observation period.

6. Security and handover

WPReborn uses reasonable safeguards for its order, support and payment flows. The security of the finished site also depends on correct hosting, deployment, third-party services and ongoing operational practices after handover.

7. Changes and additional work

Requests beyond the agreed scope are quoted or approved separately before implementation. A change that materially affects architecture, data volume, integrations, delivery timing or third-party requirements may require a revised milestone or package classification.

8. Acceptance and support

Delivery is considered ready for acceptance when the agreed scope is made available for review or production handover. Defects that reproduce against the agreed scope should be submitted through support with enough information to investigate. New features, changed requirements and third-party changes are separate work unless expressly included.