# Migrating to pools


Personal accounts don't need to do anything. Your VMs already share your
account's capacity.

Teams moving to Work set up [pools](/docs/pools) in three steps.

## 1. Create your default pool

When you switch to Work, you're asked to name your first pool and pick its
region. New VMs created without `--pool` go there.

Other team plans are no longer sold, so you can't switch back after moving to
Work.

## 2. Move existing VMs into pools

Your existing VMs stay outside any pool and keep running. An admin moves each
one in with:

```
pool adopt --vm=<vm> --pool=<pool>
```

- The VM must be running or stopped.
- The VM must fit within the pool's size. Resize the VM or the pool first if
  it doesn't.
- The VM moves to the pool's hardware, which can take several minutes.

Adopting is one-way. A VM in a pool can't go back outside a pool. The only way
out is `pool detach --vm=<vm>`, which makes it a
[standalone VM](/docs/standalone-vms) billed by the hour.

`ls --group=type` lists VMs still outside a pool under "Dedicated VMs". While
the team has any, an admin can keep new VMs outside pools too with
`team settings vm-placement poolless`. See
[Default placement](/docs/pools#default-placement).

## 3. Create more pools as needed

```
pool new build --cpus=8 --region=lax
```

Use separate pools for work you want to size, place, or track separately. See
[VM pools](/docs/pools) for sizes and pricing.

## Billing while you migrate

VMs outside a pool are not billed by the hour. Their disk and bandwidth are
still metered. Once a VM is adopted, it uses its pool's capacity, which is
billed as described in [VM pools](/docs/pools).