# Back up and migrate IIS configuration without copying the whole server

> Use appcmd backups, export site/config XML, and understand shared configuration before migrating IIS to a new host.

**Tested on**

- Build: 26100.33650
- Edition: Standard / Datacenter
- Architecture: x64
- Evidence: E1
- Verified: 2026-10-29

## The short answer

IIS configuration lives mainly in:

```text
C:\Windows\System32\inetsrv\config\applicationHost.config
```

Site-level `web.config` files also matter. A migration needs **both**, plus content, certificates and app-pool identities.

`appcmd` can snapshot and restore the server configuration. It is not a full backup of content or certificates.

## Config backup

```powershell
C:\Windows\System32\inetsrv\appcmd.exe add backup "before-change"
C:\Windows\System32\inetsrv\appcmd.exe list backup
```

Restore:

```powershell
C:\Windows\System32\inetsrv\appcmd.exe restore backup "before-change"
```

`appcmd` stores backups under `%windir%\system32\inetsrv\config\backup`. Copy them off the server; a backup on the same disk is not disaster recovery.

## Export a site

```powershell
appcmd list site "Lab" /config /xml > C:\backup\lab-site.xml
appcmd list apppool "labpool" /config /xml > C:\backup\labpool.xml
```

Import on the target:

```powershell
appcmd add site /in < C:\backup\lab-site.xml
appcmd add apppool /in < C:\backup\labpool.xml
```

Review the XML before importing: physical paths, bindings, certificate thumbprints and app-pool names may not exist on the target.

## What appcmd does not copy

- **Content** (`C:\inetpub\lab`) — copy separately with ACLs.
- **Certificates/private keys** — export/import PFX deliberately; do not copy the certificate store blindly.
- **App-pool identities** — virtual accounts are local; custom accounts/gMSA need the target setup.
- **`web.config`** — part of the content; check for machine-specific paths.
- **Logs** — evidence, not configuration.
- **Scheduled tasks/services** — separate.

## Shared configuration

For a farm, IIS can store `applicationHost.config` on a UNC share with a shared `web.config`. This is not a quick lab step:

- the share must be highly available;
- the app-pool identity needs read access;
- encryption providers/keys must match;
- a network outage can break all nodes.

Use it only when you actually need a farm; a standalone server should keep local config + backups.

> **Caution: Do not hand-edit applicationHost.config in production**
>
> A malformed XML file can stop W3SVC from starting. Use IIS Manager/appcmd, make a backup first, and keep a console/remote path to restore it.

## Migration checklist

1. `appcmd add backup` on the source.
2. Export site/app-pool XML.
3. Copy content + ACLs.
4. Export/import certificates with private keys.
5. Recreate custom identities/gMSA.
6. Import site/app pool; fix paths/bindings.
7. Test locally with Host header; then DNS/firewall.
8. Keep the old server read-only until the new one passes.

## Lab boundary

E1. The lab created `Lab`/`labpool` on Windows 11, but did not perform a cross-server migration. The commands are the planned procedure; test on Server 2025 before relying on it.

## Sources

- [Microsoft Learn — applicationHost.config](https://learn.microsoft.com/en-us/iis/configuration/system.applicationhost/)

---

Source: https://windows.homes/en/server/web/iis-config/