Can I see and change which IP each site sits on

Yes, both, and without opening a ticket. The IP Manager lists every address on the account and lets you assign one to a site or swap it for another yourself. You can review the whole allocation before pointing a single domain, and you can change an assignment later as the estate changes.

Why self-service matters more than it sounds

On a small account this is a convenience. On an account holding hundreds of addresses it is the difference between an estate you can actually run and one you administer through a support queue.

Consider the ordinary case: you run a reverse lookup on one of your addresses and find something in its history you would rather not sit beside. If reassignment is self-service, that is a two-minute fix. If it requires a ticket, it is a fix you will postpone, and postponing it is how a small problem becomes a permanent one.

The sequence that avoids rework

1. Review the allocation before you point anything. The whole list is visible from the moment the account is active. Read it first.
2. Check a sample from the outside. Reverse lookups tell you what an observer sees; the panel only tells you what you own.
3. Assign deliberately. Match sites to addresses on purpose rather than taking whatever order the list happens to be in.
4. Record which site sits where. Your own note, not just the panel. At forty sites, memory is not a system.
5. Re-check after growth. A large follow-on order is the moment to confirm the new addresses are as scattered as the first ones.

What a reassignment involves

Moving a site to a different address is an assignment change rather than a rebuild. Files, databases and mail are untouched. What does need attention is DNS: anything pointing at the old address needs to follow, including the records behind private nameservers, and the change takes as long to propagate as the record's own cache lifetime says it should.

The practical consequence is to lower the cache lifetime on those records before a planned move rather than after, so the change lands quickly instead of trailing for a day. Record caching behaviour is explained in the RFC on negative caching and TTLs if you want the underlying rules rather than the rule of thumb.

Keeping the record straight over time

The failure mode on a large allocation is not technical, it is bookkeeping. Sites get moved, addresses get freed, and six months later nobody is certain which addresses are actually in use. Two habits prevent it: reconcile your own list against the panel on a schedule, and never leave an address assigned to something that no longer exists.

The nameserver side of a move is covered in Nameservers and DNS, and how the pool is constructed is in IP Diversity.