Switching providers

Changing website providers without losing track of the important pieces

Use an inventory, written scope, and deliberate launch review to keep a website transition from becoming a larger project than intended.

By GroupHarbor · Published October 31, 2026

Begin by separating the public website from the services connected to it. Your domain, email, payments, document archives, and event tools may have different owners or providers. A clearer website does not necessarily require replacing all of them.

Inventory what people actually use

List the main pages, frequently requested documents, current forms, meeting information, and important links. Ask staff which pages residents or members rely on most. Include destinations linked from printed material, old newsletters, or other public websites.

Mark whether each item should move, stay with an existing service, be reviewed, or be retired through an authorized process. Treat a large historical collection as a separate scope decision instead of assuming it is ordinary page content.

Confirm control and authorization

Identify the people authorized to approve the purchase, change domain settings, and approve the new public content. Those may not all be the same person. Having access to an email address or an editor account does not settle every approval question.

Confirm who controls the domain and how the required technical changes will be made. Record the existing email arrangement and any services that must remain untouched. Keep credentials out of ordinary planning documents.

Agree on the work in writing

Ask the proposed provider to identify the included migration, design choices, document work, training, and ongoing support. Request a separate explanation of optional work and the cost after any introductory period ends.

A quick template setup does not tell you how long it takes to inspect a large archive, repair inaccessible files, or preserve many old links. The written scope should reflect your actual content rather than an optimistic example.

Review a private version first

Keep the new site private while staff review it. Check the information people use most, the contact details, the intended navigation, and the work staff will perform after launch.

Distinguish sample content from material intended for the official website. Try at least one routine publishing task with a named staff account. Make sure that someone other than the person building the site can understand the process.

Plan the cutover and the exceptions

Agree on the launch window, important redirects, domain changes, and how a problem would be handled. Record any outstanding content or accessibility work and who owns it. Do not let an unresolved item disappear simply because the new design looks finished.

After launch, check the important destinations and the connected services that were meant to stay unchanged. Retain the transition inventory and the agreed support route so the next person can understand what moved.

The GroupHarbor switching approach follows this same principle: understand the existing work, agree on the scope, and review the result before making it official.