Moving a municipal website to .gov without losing access

Moving a municipal website to .gov takes coordination between the people managing the domain, website and email. Assign responsibility for each part, redirect old links to the right pages, and test resident services before announcing the switch.

A .gov domain is an internet address reserved for eligible U.S. government organizations. CISA verifies the requester and the organization's eligibility (opens in a new tab) before approving it. That gives residents a way to recognize an official government address.

What should happen before moving a municipal website to .gov?

Confirm the proposed name and the people authorized to request it before setting a public launch date. CISA's request guidance (opens in a new tab) calls for senior-official approval, organization and contact details, and a Login.gov account. First-time requesters also complete identity verification.

Allow time for the request review. Approval and website readiness are separate milestones, so avoid ordering printed materials around a name that has not been approved.

For the internal plan, write down who can answer each question:

• Who is submitting the request and receiving follow-up questions?
• Who can change the settings that connect the address to online services?
• Who handles the website launch, and who handles email?
• Who will check the result with staff and authorize the resident announcement?

One provider may cover several jobs. Have them confirm the scope in writing so an unassigned email task does not turn up on launch day.

What does the technical provider need to connect?

The new address needs configuration for the services using it. DNS, short for Domain Name System, holds the records that direct traffic to the website, email and other services. CISA's setup guidance (opens in a new tab) explains how the approved domain connects to DNS hosting.

Ask the technical provider to list the services that use the current domain and identify which will change. Include any separate addresses for applications or staff systems. A domain change should not leave an older service out of the plan because it is absent from the main navigation.

New .gov domains require HTTPS connections in supporting browsers through a setting called HSTS preloading. Have the provider confirm that every website using the new domain has working HTTPS before launch, including subdomains. CISA's setup guidance applies this to internal websites too.

How do we keep old bookmarks and document links working?

Give the website provider a list of old addresses and their intended destinations. A resident opening a saved meeting packet should reach that packet or a relevant replacement. Sending every visitor to the new homepage makes them search again.

Google's site-move guidance (opens in a new tab) recommends mapping old URLs to new ones and using permanent redirects. Ask the provider to check those redirects, update the sitemap and search-engine settings, and monitor errors after launch. Search visibility can fluctuate during a move.

Keep the old domain registered. If it redirects HTTPS visits, its security certificate also needs to stay current. These are explicit points in CISA's transition guidance (opens in a new tab). Agree on who maintains them after the new website is running.

If content is moving to a new platform too, use a separate document and meeting-archive migration check. A working redirect cannot recover a file that was never transferred.

Does changing the website address also change email?

Email needs its own configuration and testing. CISA explains that many mail services support aliases, which can deliver messages sent to an old address, but the process depends on the provider. Its email transition guidance (opens in a new tab) also calls out software accounts that use an email address as their identifier.

Have the email administrator confirm how old and new addresses will work. Test messages from outside the organization and send replies back. Include shared departmental inboxes in the check, not only individual staff accounts.

Then test website forms. Submit an approved test entry without sensitive information and confirm that the right office receives it. Check any resident confirmation message for the correct contact address. A successful page load tells you nothing about whether that submission reached staff.

What should staff check before announcing the change?

Test tasks that residents actually need to complete. Ask each responsible provider to resolve failures before the public announcement, and keep the results in the launch record. Staff can verify the public experience while technical providers check the underlying configuration.

1. Open a saved agenda or ordinance link. Record whether the expected document opens from the old address. Send failures to the website provider.
2. Use a form on the new website. Check that staff receive the test entry and the confirmation is correct. Involve both website and email providers if delivery fails.
3. Follow a payment or permit link. Have the responsible department confirm that the correct service opens and its instructions still apply. Refer account or transaction issues to that service's provider.
4. Send mail to the old and new office addresses. Record whether both messages arrive as agreed and replies reach the sender. The email administrator handles failures.
5. Publish a small approved correction. Staff should be able to sign in, edit and see the public change. Ask the website provider to resolve any access problems.

Keep one issue list with an owner for each failed check. Before launch, agree on who can stop the change if a required service fails and how staff will reach that person. This is especially useful when the website and email vendors are different companies.

What should residents hear about the new address?

Give residents the exact new address, the change date and a clear explanation of what happens when they use an old link. State any action they need to take. Keep the notice easy to find from the homepage during the transition.

Sands Township in Michigan did this in its December 3, 2024 website announcement (opens in a new tab). It identified the new .gov address, pointed out the addition of "mi" to the name and told visitors that the old website would reroute automatically.

Use similarly concrete language for your community. If email changes, explain its timing separately. Name any payment or application services that retain their existing addresses, after confirming that with their providers. Give front-counter and phone staff the same notice so residents get a consistent answer.

Who handles the website after the move?

Keep domain administration and website support assigned after launch. CISA's security guidance (opens in a new tab) recommends a public security email monitored by people who can assess reports. Make sure those messages reach someone responsible for acting on them.

A .gov address does not replace software maintenance, access controls or recovery planning. The website maintenance guide helps staff identify the work that continues after a launch.

Muniway's website service includes moving pages, documents and meeting archives, and connecting your organization's domain to the new website. Your domain stays registered to your organization. Discuss the address change as part of the website plan and confirm any email work separately with the provider responsible for it.

Give the person approving launch the completed checks and any unresolved issues. If an essential form or service still fails, fix it before directing residents to the new address.