A little knowledge.
A lot more confidence.

1. Start with what you are building

A portfolio or business site usually fits shared hosting. A custom application with background workers often needs a VPS. Dedicated hardware suits heavier, sustained workloads.

2. Check the resources

Look at storage, memory, CPU limits and monthly transfer. Leave room for backups, plugin updates and traffic spikes.

3. Choose a location

Start near your main audience. If your application depends on a third-party API or database, consider its location too.

4. Plan the work around the server

Shared hosting provides a control panel. Unmanaged servers need someone to maintain updates, access controls, monitoring and backups.

1. Keep your current records

Export or copy existing DNS records before changing anything. Email records such as MX, SPF, DKIM and DMARC need special care.

2. Find your hosting details

Use the IP address or nameservers supplied with your actual hosting account. Never copy an example IP address into production DNS.

3. Update the website records

Set the root A or AAAA record and your www record as directed by the host. Changing nameservers moves management of the whole DNS zone.

4. Allow for cached records

Existing resolvers can keep old results until their TTL expires. Verify the website and email after changes have had time to propagate.

1. Take a full backup

Download your website files and export the database. Confirm that the backup can be opened and store it away from the current host.

2. Check compatibility

Compare PHP versions, extensions, database support and storage. Update incompatible plugins in a test environment first.

3. Restore and test

Upload files, import the database and update connection settings. Test logins, links, forms and checkout before sending visitors to the new host.

4. Switch DNS and monitor

Reduce the DNS TTL in advance where possible, switch records, then watch traffic and errors. Keep the previous hosting available during the transition.

1. Connect using the supplied credentials

Verify the connection details provided for your server. Add an SSH public key and verify key-based login before removing password access.

2. Create a regular admin account

Use a non-root account with the necessary sudo privileges for daily administration. Keep a recovery path available.

3. Apply updates and set a firewall

Update your OS and allow only the ports the application needs. Confirm SSH remains reachable before ending the current session.

4. Set up backups and monitoring

Store backups outside the instance and test a restore. Monitor disk use, memory and your application’s health.

5. Document the setup

Record installed services, deployment steps and recovery procedures. Do not place passwords or private keys in the document.

1. Choose what matters

Include site files, databases and configuration. Some applications need consistent database snapshots, not just a file copy.

2. Separate the copies

Keep at least one copy outside the primary hosting account or machine. A backup on the same disk shares the same risk.

3. Set a retention schedule

Match backup frequency to how much data you can afford to lose. Keep more than one restore point.

4. Test the recovery

Restore to a separate environment, verify content and record how long it takes. Repeat the test after significant application changes.

1. Use the invoice details

When live billing is available, pay only the asset, amount and network specified on the invoice. Do not reuse an old payment address.

2. Check the network carefully

USDT on Tron is different from USDT on Ethereum. Confirm that your sending wallet supports the invoice’s network.

3. Account for fees and expiry

Network fees and exchange withdrawal fees may affect the amount received. Read the final invoice total and expiry before sending.

4. Wait for confirmation

A broadcast transaction is not yet a completed payment. The billing portal must verify the transaction and required confirmations before marking the invoice paid.