Running a hostA practical hosting platform launch checklist

This is a launch checklist for putting a hosting platform — new, or newly migrated — in front of real customers. It is ordered by cost of late discovery rather than by convenience, so the money and the irreversible operations come first.

1. Money

1. Issue an invoice end to end and read it as a customer would. Check tax, currency, the business name and the payment instructions.
2. Record a payment against it and confirm the balance is right. Then record a part payment against another and confirm that too.
3. Apply a credit and check the resulting balance, the credit note and the audit line.
4. Confirm the number series is sequential with no gaps, and that two people issuing at once cannot take the same number.
5. Confirm a refund requires a deliberate act by an authorised person and leaves a record.
6. Check what a customer sees when they owe nothing. An empty state that looks like a failure generates support tickets.

2. Provisioning

1. Create an account for a real product on a real server, by the normal path.
2. Suspend it. Confirm the customer's site actually stops, and that the customer-facing status says why in words.
3. Reinstate it. Confirm it comes back without manual work.
4. Simulate a lost outcome — pull the network, or point at an endpoint that hangs — and confirm the system stops rather than retrying.
5. Resolve that unknown outcome by hand, both ways: once where the account exists and once where it does not.
6. Confirm two simultaneous creations for the same account name produce one account and one clear refusal.
7. Confirm termination is not reachable from any automated path.

3. Access

1. Every staff member has their own login. No shared accounts.
2. Each role can do its job and cannot do the next role's. Test by attempting, not by reading the settings.
3. A member removed from a workspace loses access on their next request.
4. A record from another workspace answers exactly as one that does not exist.
5. Provider credentials cannot be read back by anybody, including an owner.

4. Recovery

1. Restore last night's backup into an isolated environment and bring the application up against it.
2. Time it, and write the number in the runbook.
3. Confirm the runbook is followable by somebody who did not write it.
4. Confirm you know where every credential comes from that is not in the database.
5. Rehearse rotating one provider credential without an outage.

5. The customer-facing surfaces

The day itself

• Move one friendly customer first, and watch everything they do for a day.
• Keep the old system readable, and tell support which one is authoritative for what.
• Have a rollback decision point with a time on it, agreed before you start.
• Do not launch on a Friday, and do not launch during a renewal peak.

Where GENV is

To be direct about it: GENV is in active development, and no provider integration has been certified against a live production installation. Provisioning modules are built, configurable and exercised against deterministic stand-ins, and effecting actions are not routed in the shipped build. That means GENV today is a system you can evaluate, migrate data into and run internally — and not one to put a customer's live hosting behind. This site says that on every page where it is relevant, rather than in the small print.

Questions