Launch is the start of it, not the end.

• Choose website and server migration when only where the site runs changes.

  A move to a new host, server or cloud platform, with the same design and page addresses, is planned, rehearsed and verified under website and server migration.

• Look to website redesign when the addresses or platform change too.

  When page addresses, the platform or the domain change, redirects and search equity become the main risk, which website redesign and modernization and SEO migration support cover, with the infrastructure work here.

• Start with staging and pipelines when changes go straight to the live site.

  If edits are made directly on the live site, a staging environment and automated checks come first, because every later change depends on having a safe place to test it.

• Choose a website care plan when the site needs work every month.

  When a site brings in business and changes often, tested updates, one route for problems and routine checks sit on one written scope under website care plans.

• Pay for support as needed when changes are rare and downtime costs little.

  A site that changes once or twice a year can be supported when work arises, as long as someone still applies its security updates on a schedule.

Setting up a domain, DNS and hosting means registering the domain in an account the business owns, choosing hosting that fits what the site runs, and creating the DNS records that point the domain at the website, the email service and any platform verification. Every record, account and renewal date is then documented.

The domain is registered, or transferred, into an account in the business name, with automatic renewal switched on where the registrar offers it. Hosting is chosen from what the site actually runs and sized from measurement, which is covered under performance and security, rather than from the name of a plan.

A name that holds a CNAME record should hold no other data, so the root of a domain, which always carries other records, normally points at hosting with A or AAAA records. Redirecting HTTP to HTTPS and sending HSTS belong to security hardening under performance and security, and watching renewal dates over time is part of maintenance and support.

The records a typical setup needs are these, each documented with what it does and why it exists:

• A records, which point a name at an IPv4 address.
• AAAA records, which point a name at an IPv6 address.
• CNAME records, which make one name an alias of another.
• MX records, which name the servers that receive email for the domain.
• TXT records, which carry email authentication and platform verification values.
• CAA records, which name the certificate authorities allowed to issue certificates for the domain.

Business email on a company domain is set up by choosing a mail provider, creating the users and mailboxes first, then publishing MX records that direct incoming mail to the provider and SPF, DKIM and DMARC records that let receiving servers check that mail using the domain is genuine.

Each record has one job. MX records tell a sending server where mail for the domain is delivered, and a sending server looks them up first. SPF lets the domain authorize the hosts allowed to send mail using its name. DKIM adds a cryptographic signature that receivers verify with a public key the domain publishes. DMARC tells receivers how the domain owner wants failed checks handled and where reports should go; its current specification was published in May 2026.

Large mailbox providers now expect this from domains that send in volume. Outlook.com requires domains sending more than 5,000 emails a day to its consumer addresses to pass SPF and DKIM and to publish a DMARC policy.

The work here is configuring the provider the business chooses: the records, the users and, where the provider supports it, moving existing mailboxes. Mail servers are not operated here, and sending automated messages from forms, stores and workflows is covered under integrations and automation.

The right hosting follows from what the site runs. A prerendered site can be served from a platform with a content delivery network, a content-managed site needs a server or managed platform for its application and database, and a custom application needs an environment sized from its measured load.

Server configuration is practical work: the runtime the application needs, a reverse proxy in front of it, automatic restarts, logging, and access limited to the people and keys that need it, each with the least privilege that does the job.

Configuration lives in the environment rather than in the code. A useful test is whether the codebase could be made public without exposing a single credential; if it could not, a secret is still in the wrong place. How API keys and tokens are stored is covered under integrations and automation.

Cloud capacity is added when measurement shows it is needed, using the measurements taken under performance and security, rather than bought in advance on an estimate. No hosting choice makes a site scale without limit, and no provider is recommended before the site has been assessed.

Where a CDN is used, its configuration decides what may be cached. A response marked private must never be stored in a shared cache such as a CDN, so signed-in pages, carts, responses that set cookies and API responses are excluded, and caches are purged in each release. Firewall rules at the edge can also block search engine crawlers by mistake and keep a site out of search results, so crawler access is checked, and a temporary block returns a 503 or 429 status. Why caching makes a site faster is covered under performance and security.

Staging and deployment pipelines make releases safer by testing each change in an environment that mirrors production, running automated checks before anything is released, and keeping every release identifiable so the previous one can be restored. The live site stops being the place where changes are tried for the first time.

Each release is built once, given its own identifier and never changed after it is created, so rolling back means redeploying a known release rather than undoing edits by hand. Pipeline logs are kept free of secrets.

Staging is set up where a project release process calls for it. A small site may need only a private preview of each change, while an application with customers and integrations usually needs a full staging environment. Purging caches after a release is part of cache invalidation, covered under performance and security.

A recommended pipeline, adapted to each project, runs in this order:

1. A change is reviewed in version control.
2. Automated checks run: type checks, tests and a build.
3. The same build is deployed to staging.
4. The change is tested and approved on staging.
5. The approved build is released to production.
6. A health check confirms the site responds as expected.
7. Caches are purged where the release changed them.
8. If the check fails, the previous release is restored.

Backups and disaster recovery are planned by first agreeing how much recent data the business could lose and how long the site could be unavailable, then configuring backups, storage and retention to meet those limits, writing down the recovery steps, and testing a restore so the plan is proven before it is needed.

Those two limits have names. The recovery point objective is how far back from a failure data can be recovered, and the recovery time objective is how long a system can stay unavailable before the harm becomes unacceptable. Both are set with each business rather than assumed, and the recovery time objective normally has to be shorter than the longest outage the business could tolerate.

A restore is rehearsed before anyone relies on it, because testing is what turns a plan into a capability. The plan also records where copies are encrypted and the order in which dependencies such as DNS, email and third-party services come back. What makes a single backup recoverable is covered under performance and security, and running backups and restore tests on a schedule is part of maintenance and support.

A written recovery plan usually runs in this order:

1. Detect the failure and confirm what is affected.
2. Decide whether to repair in place or recover.
3. Restore the application, data and configuration.
4. Validate the restored site before traffic returns.
5. Restore service and tell the people affected.
6. Review what happened and update the plan.

Content changes, small new features and bug fixes on a live site are handled through one route: the request is recorded, prioritized by its effect on the business, made on a copy of the site, tested, and released with a way back. Content editors can still change routine text themselves where the site gives them that access.

Change requests are handled differently by size. A correction to a price, a phone number or a paragraph is small and is handled within the agreed scope. A new section, form or page template is an enhancement, built and tested like any other release. A substantial feature, such as a booking system or a new integration, is scoped as its own project, then maintained once it is live.

Bug fixes follow a set sequence from report to verification, and they are prioritized by what the fault breaks: a failing checkout or form comes before a layout fault on one page. How a care plan runs that sequence, and what a useful bug report includes, is covered under website care plans.

Security and platform updates need testing because an update can change behavior the site depends on: a plugin, library or framework release can alter a feature, break a form or conflict with another component. Testing on a copy of the site first means a security fix can be applied promptly without trading one risk for another.

Updates arrive in three kinds. Security releases fix a known vulnerability and are applied soonest. Routine releases bring fixes and small changes, and are grouped into the regular update cycle. Major versions change how a platform or framework works, and are planned as a small project with their own testing, because they can remove features the site still uses.

Each update is recorded with what changed and when, so a fault that appears later can be traced to it and the release reversed if needed. Engineering security itself, including audits, hardening and security headers, belongs to performance and security, and maintenance keeps that work current.

Website monitoring covers the checks that notice problems, such as the site not responding, a certificate nearing expiry, pages dropping out of search or a slower release. Technical support covers diagnosing and resolving the problems that checks or people report, including hosting, deployment, integration and configuration issues, through a written route agreed with the business.

Monitoring is configured for each site in accounts the business owns, with alerts going to named people. Performance monitoring watches page speed and Core Web Vitals after releases, so a regression can be traced to the change that caused it. SEO monitoring watches indexing, sitemaps, metadata and broken links, so a page that drops out of search is noticed. What is watched, and how often, is written into the arrangement, and no uptime percentage is promised.

Backup management is the routine side of the recovery planning covered on this page: checking that scheduled backups ran, that copies are stored away from the live system, and that a restore still works when it is tested. It applies where the maintenance arrangement includes access to the systems that hold the backups.

The checks a maintenance arrangement can include are these:

• The site responds, and important pages load without errors.
• Certificates renew before they expire.
• Page speed and Core Web Vitals hold after each release.
• Important pages stay indexed, and sitemaps stay valid.
• Links and forms still work.
• Scheduled backups ran, and a test restore succeeds.

Maintenance is usually the longest stage in the life of a website. A site is discovered, designed, built and launched once, then monitored, maintained and improved for as long as it runs, and what maintenance finds, from slow pages to confusing forms, becomes the input for the next round of design and development.

Not every project passes through every stage with the same team, and a site can join at any point, such as a site built elsewhere that now needs a care plan. Each stage connects to a part of the service catalog, which is why the categories on this site are built to hand work to each other. The stages run in this order:

1. Discover: goals, users and search demand, under UI/UX and SEO.
2. Design: interface, content structure and brand, under UI/UX and branding.
3. Build: the website or application, under web design and development or web apps and SaaS, with integrations and automation or AI solutions where it needs them.
4. Launch: hosting, deployment and migration, under hosting and infrastructure.
5. Monitor: performance, security and search checks, under maintenance and support.
6. Maintain: updates, fixes and content changes, under website care plans.
7. Improve: measured changes, under analytics and conversion optimization and SEO.

A website depends on several layers, often held in different accounts. Knowing who holds each one is what makes changes, moves and recovery possible.

• Domains, DNS, hosting and certificates are registered or configured in accounts the business owns, and where each record and credential is held is documented.
• Certificates renew automatically, because the maximum lifetime of public TLS certificates is being shortened in stages.
• A release is built once, tested on staging where the project uses one, and promoted to production with a way back, never edited on the live server.
• Recovery objectives are agreed with the business before backups are configured, and no recovery time is stated that has not been tested.
• Maintenance follows the same release path as the build: a change is tested before release and planned with a way back.
• Maintenance access is individual, held in accounts the business owns, and removed when the work ends.
• What a maintenance arrangement includes, and how problems are reported and prioritized, is written down before it starts, and nothing is promised that the scope does not state.