Server upgrades, reinstalls and migrations

RimuHosting can help update an existing server, rebuild it with a clean operating system, or move its websites, email and other services to another server. We can also help move hosting from another provider or consolidate several servers.

The aim is to agree what needs moving, how we will test it, and how we will switch over. Please work through the questions below and send your answers in a support ticket. Answer what you can; "not sure" is fine. We can inspect the server to fill in many of the gaps, but please tell us about anything important that may not be obvious from its configuration.

Choose the approach

Update packages on the current operating system. This is often the smallest change when the operating system and the required application packages still receive updates. A package update does not necessarily move an unsupported operating system onto a supported release.

Upgrade the operating system in place. This can avoid rebuilding the whole setup, but it may change PHP, databases, web-server configuration and other dependencies. We may use distrorejuve to help with suitable upgrades. Its inventory and before/after reports help identify changes; we still need to check the websites and applications themselves.

distrorejuve: https://github.com/pbkwee/distrorejuve

Reinstall and rebuild on the existing VPS. A clean reinstall gives the server a fresh operating system. We can then selectively migrate data and recreate the required configuration from the original image or backups. This normally needs downtime while services are rebuilt. As part of the reinstall, we retain the old VM image in a backup location. You can mount that backup image to access its files. It is typically available for at least seven days. We will not remove it while it remains mounted or attached to your VM. Tell us before detaching it if you need longer retention. The retained image contains the server as it was before the reinstall; keep separate backups of subsequent changes.

Migrate to another server. Building the destination separately lets us test it before switching traffic over and can reduce the final outage. We still need a final data sync and a plan for writes, email and scheduled jobs during the change. You can order a new server if needed.

If retaining the existing IP address is important, tell us before we choose the approach. One option may be to build and test on a temporary VPS, then reinstall the original VPS from the prepared image while retaining its IP address. That replaces the original disk contents and needs an agreed final sync and outage. We will confirm what is possible for the servers and locations involved; retaining an IP address should not be assumed.

If the server may have been compromised, tell us at the start. A clean rebuild may be appropriate, with checked data restored selectively and affected credentials replaced. Copying the entire old setup can copy the compromise too.

Downtime and changes during the work

Upgrading in place or rebuilding the existing VPS. Plan for public services to be unavailable until the upgrade or rebuild, compatibility fixes and checks are finished. An in-place upgrade can mean a couple of hours to a few days of downtime, depending on custom code, application compatibility and configuration problems. We will discuss the likely window for your setup. Elapsed downtime and billable sysadmin time are different.

While the affected services are stopped, visitors cannot use those websites or submit new posts, orders, comments or uploads. A stopped local mail service cannot receive or send mail. Some sending servers may queue messages and retry later, but delivery is not guaranteed. External applications may also retry failed payments, API calls or notifications, so we need to consider those entry points.

Preparing a separate server. The old server can keep serving customers while we build and test the replacement. However, an initial copy becomes out of date as soon as the old server changes. Later changes can include:

• Database updates such as orders, posts, comments, account changes and payment records.
• Uploaded, edited, renamed or deleted files, application sessions and queued work.
• Received and sent email, mailbox folders, read/deleted flags, outgoing mail queues and changes to mail accounts or forwarding rules.
• Scheduled-job results, external callbacks, deployments and configuration changes. Tell us whether recent logs or audit records also need preserving.

We need an agreed way to transfer those changes before the new server takes over. Usually this means pausing writes and background jobs on the old server, making a final consistent database and file transfer, checking the result, then starting the destination services. Mail needs its own plan for queued or late-arriving messages. Replication or application-specific tools may reduce the pause where the setup supports them.

A second file copy cannot safely merge arbitrary database changes. If both servers accept new data, reconciling those changes can be difficult and may not be possible without losing or overwriting data. Deleted files, already-sent messages and completed payments also need different handling from new files. We should agree how to handle each source of changes before promising a final sync or a short outage.

Start with the plan

• Which server are we updating or migrating from? Include its hostname, IP addresses and RimuHosting server/order reference, if known.
• What is the reason for the work: security updates, an unsupported operating system, a suspected compromise, a change of provider, consolidation, or something else?
• Which destination server and operating system should we use? Tell us if you would like a recommendation.
• Are there required application, PHP or database versions, or software licences that constrain the choice?
• When may we start? Include your time zone and any dates or times to avoid.
• What is the longest acceptable outage? Distinguish preparation time from the period when customers cannot use the service.
• Who can answer questions, test the new setup and approve the final switch? Include an agreed way to reach them during the work.
• What backups are available, how recent are they, and has a restore been checked?
• Do you require a quote or a spending limit before work starts?

Access and working arrangements

For a RimuHosting server, first check whether our existing SSH access is working. Our SSH access guide explains that access and links to the SSH access check page. Tell us about a custom SSH port, firewall restrictions or a required non-root login with sudo.

For other source or destination servers, tell us the SSH hostname and port, account name, and whether administrative/root access is available. If you only have a hosting-panel account, provide the panel URL and explain its access limits.

Do not put passwords, private keys or API tokens into this checklist or an inventory report. We will agree how to provide any required access securely. Temporary access is preferable where practical. Tell us if an administrator or developer needs to be available to grant access or change application settings.

Tell us whether we should put up a maintenance page, which sites it should cover, and the wording to use. You can supply static HTML, images and CSS. Also identify APIs, background workers or other entry points that need pausing; a website maintenance page alone may not stop changes to the data.

Using AI tools

AI tools can help explain an unfamiliar setup, interpret errors, review configuration and suggest migration steps or code changes. You may find them useful for doing some of the work yourself. For example, a distrorejuve inventory can help you and an AI tool build a checklist of services and dependencies that need attention.

We may also use AI tools to assist with migration work. Please tell us explicitly before work starts if you require us not to use AI, or if you have restrictions on particular tools or the information they may process. Those requirements can affect troubleshooting options, time and cost, and what we can complete within the agreed budget. We will discuss the approach with you.

Some AI tools send supplied information to an external service. Tell us about confidentiality, privacy or data-handling requirements so we can agree which tools and information are suitable. If you use AI yourself, review and remove sensitive information before sharing configuration, source code, logs or inventories. Do not include passwords, private keys, API tokens or customer records.

AI suggestions can be wrong or miss parts of the setup. Review commands and scripts before running them, especially when they change packages, databases, files or services. Keep recoverable backups and test the applications after changes. AI assistance and a successful distrorejuve run do not establish that a website, email service or custom application works correctly.

Websites and applications

For each site or application, list:

• Its main domain, aliases and subdomains, including staging sites and applications reached by IP address, unusual ports or URL paths.
• What it does, who maintains it, and its important files, uploads or other data directories, if known.
• Its software and required versions: for example WordPress, Moodle, Joomla, a custom PHP application, Java/Tomcat, Ruby, Python or Node.js.
• The PHP version used by the website, any required extensions, and any PHP-FPM pools or special PHP settings you know about. The command-line PHP version may differ from the website's version.
• Redirects, proxy/backend services, WebSockets, authentication rules, aliases, rewrites, FastCGI, suexec or other special web-server settings.
• HTTPS certificate names, how certificates are renewed, and who controls any required DNS or certificate-provider account.
• Connections to external databases, storage, SMTP relays, payment providers, APIs or other services. Tell us if access is restricted to the current server's IP address.
• Any application changes or version upgrades you want included, or settings that must remain unchanged.

Please give us a few useful test URLs and the expected result. Include important actions such as signing in, searching, uploading a file, submitting a form, sending email or using an API. We will agree how to test actions that could charge a card, send messages or change real customer data.

Email

Is email hosted on this server, or elsewhere such as Google Workspace, Microsoft 365 or 25 Mail St.? A website move does not necessarily require moving its email.

If email is hosted locally, please identify:

• The mail domains and mailbox accounts to migrate, including existing messages, folders and shared mailboxes.
• Aliases, forwarding addresses, catch-all addresses, mailing lists, auto-responders and filtering rules.
• Webmail, spam/virus filtering, SMTP relays, and applications that send mail through this server.
• The hostnames and ports used by mail clients, and any certificate or authentication requirements.
• Who controls MX records, reverse DNS and SPF/DKIM/DMARC settings, and whether any IP-based allowlists need changing.

We may be able to preserve existing accounts and password hashes without collecting mailbox passwords. We will confirm what is possible; some moves may require password resets or client-setting changes.

If mail can arrive at the old server during the move, we need a plan to transfer those later messages and avoid losing or delivering them twice.

Databases

List the database engines and versions, database names, and the applications that use them. Include remote database services as well as databases on the server.

Tell us about required users and permissions, extensions/plugins, stored routines, scheduled database jobs, replication, and any special character-set or collation requirements. Identify any databases that should not be copied.

Do not include database passwords here. For changes between database versions, we will choose a suitable export/import, replication or other supported migration method. Copying live database files is not generally a substitute for a consistent database migration.

Other services, storage and scheduled work

Please list anything else the server does, including:

• Cron jobs, systemd timers, queue workers and other scheduled or background work. Mention business tasks even if you do not know how they are scheduled.
• Custom services, application servers, containers and deployment tools, including their versions and configuration locations where known.
• FTP/SFTP, jailed or chrooted accounts, VPNs, firewalls, monitoring and alerting.
• Additional disks, mounted filesystems, NFS/S3 or other remote storage, and data outside the usual website or home directories.
• Backup jobs and destinations, retention requirements, and any restore procedure we need to retain.
• System users, home directories, groups and file-ownership requirements. Tell us which accounts should be removed rather than migrated.
• Hosting panels, licences and any special access or IP-address requirements.

Agree the final switch

Before changing traffic, we should agree:

• Who controls DNS and which records need changing, including IPv4 and IPv6 records and any email-related changes.
• A short list of URLs we can open to check each site before and after the switch. Include the main page, login page and important application or read-only status pages, with the expected result. Identify any checks that require an agreed test account; do not put credentials in the URLs.
• How we will reach and test those URLs on the new server before changing public DNS. For HTTPS, tests need to use the correct hostname and certificate.
• When writes will be paused on the old server, when the final files and database changes will be copied, and when writes may start on the destination.
• Which scheduled jobs, queue workers and mail services must stay stopped on the destination until the switch, so both servers do not perform the same work.
• Who approves the switch, what checks must pass, and what would make us stop or roll back.
• How long we should retain the old server and any additional backups. A reinstall retains the old VM image as described above; tell us if you need it beyond the usual retention period.

If we control the affected DNS, we can make the agreed changes. If someone else controls it, they need to be available. Lowering DNS TTLs in advance may help, but cached records and existing connections can continue reaching the old server for a while.

Rollback also needs a data plan: once customers have written new data on the destination, simply pointing traffic back may lose those changes.

Checks after the move

We will use the agreed checks to review the migrated setup. Please also test the parts of your application you know best and tell us about anything unexpected.

Checks may include websites and HTTPS, logins, uploads, database access, inbound and outbound email, scheduled work, backups, monitoring and access permissions. A running service, an open port or an unchanged inventory is useful evidence, but does not establish that an application works correctly.

Please confirm who will sign off the migration. Keep the old setup available until the agreed checks, final sync and retention requirements have been satisfied. Do not cancel the old server just because the new website loads.

Billing

Migration work is billable sysadmin time. For new customers migrating from another provider, we can provide the first hour of migration work at no charge. That can cover many simple setups; additional work is billable.

A straightforward migration often takes around 1-3 hours of sysadmin time. Data transfers, application changes, testing and the agreed change window can make the elapsed time longer. This is an estimate, not a fixed price or outage commitment.

Please tell us if you need a quote before we start, or specify the amount of billable time you approve. We will confirm the scope and any further work needed.

Sysadmin service information: https://rimuhosting.com/knowledgebase/rimuhosting/sysadmin-services