Mapping sites to IPs before you place an order

Decide which site lands on which address while the whole estate is still rows in a document, and finish that before the order goes in. Knowing the quantity is a different job from knowing the assignment; the quantity question is settled under sizing and selection. Assignment is where estates quietly go wrong, because it is the decision most people never actually make.

Why the map belongs on paper first

An address that is already serving a live site is not free to move. Changing it later means a DNS edit plus the wait for old records to age out, a certificate that may need reissuing, and reverse records to redo. On a blank sheet the same change costs you one keystroke.

Paper also shows you the estate all at once. In a control panel you look at one site at a time, so you never see that your busiest property ended up beside the one you would happily delete. And the document is the only part of this that survives a laptop rebuild, a handover, or the twelve months between now and the next time you think about it. Write the reason next to each assignment, not just the assignment, so future you knows whether a pairing was deliberate or accidental.

Grouping rules when two sites must share

A shared address is fine when the sites are compatible on every row below, not merely on the first one.

Which site gets the quietest neighbourhood

Rank candidates by what a neighbour's bad day would cost you, and give the emptiest address to whatever sits at the top: the property that takes payments, the one bound by a client agreement, or the one that sends mail your business depends on. Then defend that empty space. The usual failure is filling it six weeks later because it looked spare. Note the address as reserved in the document, with the reason. If you also want assignments spread across separate ranges rather than merely separate addresses, plan that at the same time and pick a product that supports it, such as wider range separation. None of this raises rankings. It limits how far one incident travels.

The accidental assignment

On setup day the panel offers free addresses in its own order, and sites get typed in whatever order they came to mind. The result is a layout nobody chose: the noisiest site next to the most valuable one, two unrelated clients sharing, staging sitting on production's address. Nothing warns you, and it looks tidy from the inside. The only defence is bringing the sheet to the session, assigning each hostname explicitly against it, and verifying afterwards with a lookup per hostname instead of trusting the panel summary.

What the finished map should contain

• Every hostname on its own row, including subdomains and the www form, since these do drift apart.
• The assigned address, and a running occupant count per address.
• Owner and role for each row: production, staging, or internal.
• One line of reasoning per assignment, phrased as what a shared fate would cost.
• The intended reverse DNS name, and whether that host sends mail.
• Which addresses are deliberately held empty, and what they are being held for.
• The date and the person who assigned it, so a later surprise has an author.

Take that document into provisioning and the setup session becomes transcription rather than decision-making, which is exactly what you want on a day with many moving parts. The wider sequencing around it is covered in launch playbooks.