--- title: "Migrate from VPS to dedicated server without surprises | StreetHosting" description: "How to migrate from VPS to a dedicated server: steal time, vCPU ceiling and io wait signals, inventory, low TTL, cutover window and rollback plan." url: "https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server" type: "page" language: "en-US" --- Infrastructure · 10 min · Advanced Published on Sep 15, 2026 · Updated on Sep 15, 2026 # VPS to dedicated server: when and how to make the switch The VPS held up fine to a point, and now every night's peak tanks performance. This guide shows how to confirm the limit really is the machine and how to carry out the move to a dedicated server with a rollback plan ready. By [Equipe StreetHosting](https://streethosting.com.br/en/autores#equipe-streethosting) · StreetHosting infrastructure and support team [Migration](https://streethosting.com.br/en/guides/topics/migration) [Hardware and datacenter](https://streethosting.com.br/en/guides/topics/hardware) Summarize with: [](https://chat.openai.com/?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fmigrate-vps-to-dedicated-server.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "ChatGPT") [](https://claude.ai/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fmigrate-vps-to-dedicated-server.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Claude") [](https://www.google.com/search?udm=50&aep=11&q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fmigrate-vps-to-dedicated-server.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Google AI Mode") [](https://x.com/i/grok?text=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fmigrate-vps-to-dedicated-server.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Grok") [](https://www.perplexity.ai/search/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fmigrate-vps-to-dedicated-server.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Perplexity") Share: [](https://x.com/intent/tweet?text=Migrate%20from%20VPS%20to%20dedicated%20server%20without%20surprises&url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fmigrate-vps-to-dedicated-server "Share on X") [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fmigrate-vps-to-dedicated-server "Share on Facebook") [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fmigrate-vps-to-dedicated-server "Share on LinkedIn") [](https://wa.me/?text=Migrate%20from%20VPS%20to%20dedicated%20server%20without%20surprises%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fmigrate-vps-to-dedicated-server "Share on WhatsApp") For agents: Copy as Markdown [.md](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server.md) In this guide 7 sections * [The signs that it is time](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#sinais-de-limite) * [Confirm the diagnosis with numbers](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#confirmar-com-numeros) * [Inventory of what runs today](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#inventario) * [Prepare the dedicated server in parallel](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#preparar-em-paralelo) * [Move data and lower the TTL](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#mover-dados-e-dns) * [The cutover window](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#janela-de-corte) * [Validation and rollback plan](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#validacao-e-volta) Quick answer You should **migrate from VPS to a dedicated server** when the same bottleneck comes back every week even after optimizing the application: high steal time at peak hours, vCPU pinned at the ceiling for long stretches, io wait during backups and imports, or the combined cost of several instances exceeding the price of a whole machine. The migration itself is predictable when done in this order: inventory, dedicated server prepared in parallel, low TTL, short cutover window, validation and a rollback plan ready. ## The signs that it is time[](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#sinais-de-limite) Almost nobody migrates out of a desire to swap hardware. They migrate because something started hurting on a regular basis. The problem is that the symptoms of a VPS at its limit look a lot like the symptoms of a poorly optimized application, and switching machines without that diagnosis means paying more to feel the same pain a few months later. Four signs point to an infrastructure limit rather than a code one. They carry different weight and none of them decides on its own. * **Consistent steal time.** Your virtual machine asked for processor and did not get it, because the host was serving another workload. This is not something you fix from inside the VPS. It is the most direct sign of resource contention. * **Peaks hitting the vCPU ceiling.** Usage near the maximum for long stretches, not for seconds. When the graph flattens at the top during the busiest hour, the machine has become the limit. * **High io wait.** Processes stalled waiting on disk during backups, data imports or index rebuilds. It shows up as unexplained general slowness with an idle processor. * **The sum of the monthly bills.** The least technical sign and sometimes the most decisive. When you maintain six, seven or eight instances and the total bill has already passed the price of a dedicated server, the cost of administering all of them is pure waste. Before concluding that the machine is the limit, rule out the cheap causes: a database query without an index, a log growing without rotation, a process with a memory leak and no swap configured. They produce exactly the same symptoms and cost nothing to fix. ## Confirm the diagnosis with numbers[](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#confirmar-com-numeros) Gut feeling is no basis for deciding on a monthly spend in the range of a dedicated server. Collect data for at least two weeks, covering the busiest days, and look at the metrics below. The guide on [monitoring VPS resources with htop and netdata](https://streethosting.com.br/en/guides/vps/monitor-vps-resources-htop-netdata) covers the tools. | Metric | Where to look | What indicates a machine limit | | ------------------- | ------------------------------------ | --------------------------------------------------- | | Steal time | The st column in top or htop | High value repeated at the same time every day | | CPU usage | netdata history or the control panel | Plateau at the top during peak, not isolated spikes | | Io wait | The wa column in top | High with idle CPU, especially during disk routines | | Available memory | The free command | Swap in constant use, not just during a rare peak | | Application latency | Response log or external monitoring | Response time rises along with the items above | Two weeks of collection is not overkill. A game server behaves differently on weekdays and weekends, and an online store has campaign days. If you only look at a quiet Tuesday, you will conclude everything is fine. If you only look at the Saturday of an event, you will conclude you need the biggest dedicated server available. What matters is the repeated pattern, and it only shows up with history. Always cross-check two sources. High steal time together with a rise in application response time at the same hour is strong evidence. High steal time on its own, with no noticeable impact on users, does not yet justify the switch. ## Inventory of what runs today[](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#inventario) This is the step that saves the most time later and the one most people skip. The goal is to write down, in a single document, everything that exists in the current environment. Migrations almost always go wrong because of something nobody remembered was there: a scheduled script, an old firewall rule, a manually issued certificate, an integration that only works from that IP address. * List of every running service and the port each one uses. * Exact versions of the OS, database, application runtime and critical libraries. * Scheduled tasks, including the ones that run once a month. * Firewall rules and allowlisted address lists. * Certificates in use, with expiration date and renewal method. * External integrations that depend on the current IP address. * Licenses tied to hardware or to an IP address. * Actual volume of data to move, measured rather than estimated. * Users, access keys and who holds credentials for each service. * Every DNS record pointing at the current server. Pay special attention to the IP address. Payment gateways, mail servers and partner APIs usually grant access by address. Each of those needs an update request filed in advance, and some take business days to process. Finding that out on the night of the cutover is the classic scenario of a migration that drags into the small hours. ## Prepare the dedicated server in parallel[](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#preparar-em-paralelo) The golden rule is that the dedicated server needs to be complete, working and tested before it receives its first real user. You pay for both environments for a few days, and that cost is cheap next to the price of a botched migration. With the [dedicated machine](https://streethosting.com.br/en/dedicated) active, rebuild the environment in the order below. 1. Install the operating system on the same major version that runs on the VPS today. Changing distribution and machine at the same time doubles the variables in any future problem. 2. Apply security hardening before any service: SSH key, firewall, a user without administrative privileges and blocking direct login as root. 3. Bring up the services on the exact versions from the inventory and check each configuration file against the original, not from memory. 4. Restore a recent copy of the data and validate its integrity. This is the first real test of your backup routine. 5. Test the whole application through the dedicated server's IP address, editing the hosts file on your own machine to simulate the domain already pointed there. 6. Set up monitoring pointed at the new server before the switch, so you have a baseline for comparison. Take advantage of having the whole machine to reorganize what was scattered. If today you have the database on one VPS and the application on another, on the dedicated server the two talk over the machine's own local network, which removes one network round trip from every query. ## Move data and lower the TTL[](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#mover-dados-e-dns) Copying the data happens in two stages. The first is the full load, done calmly days ahead, without rushing and without stopping anything. The second is the incremental sync at cutover time, which moves only what changed since the first load. That split is what turns a window of hours into a window of minutes. Lower the TTL of the DNS records that will change to a short value at least 48 hours before the switch. The TTL tells resolvers all over the world how long they may keep the old answer cached. If it sits at 24 hours at the moment of the cutover, some of your users will keep arriving at the old server for a full day, writing data to a place you already consider retired. While both servers are receiving traffic, duplicate writes to different databases are the worst possible outcome, because reconciling them afterwards is manual work. Better to leave the old application in read-only mode during the window than to risk writes on both sides. The generic provider switch procedure, with more detail on the DNS and propagation part, is in [how to migrate a server without downtime](https://streethosting.com.br/en/guides/infrastructure/migrate-server-without-downtime). That guide covers moving house while keeping the same type of hosting. This one covers what changes when the destination is an entire physical machine, which is where hardware-bound licenses, consolidating services that used to be separate, and the different sizing of disk and memory come in. ## The cutover window[](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#janela-de-corte) Pick the time of genuinely lowest traffic for your audience, measured in your own monitoring, not the time that seems quiet. Notify users in advance, with a date and estimated duration. Have the team available during and after, because the critical moment is not the cutover, it is the hour that follows. 1. Freeze changes on the old application. No new deployments in the hours leading up to it. 2. Put the old application in maintenance or read-only mode. 3. Run the final incremental data sync and compare record counts on both sides. 4. Bring the application up on the dedicated server and test it through the IP address, without touching DNS yet. 5. Change the DNS records to the new address. 6. Watch the new server's log and the old one's side by side until traffic has fully moved over. One thing that helps a lot is writing this sequence out as a runbook, with the exact command for each step, and rehearsing it in a test environment first. During the cutover nobody should be thinking about what the next step is, only executing a list they already know. If two people take part, decide beforehand who executes and who verifies, because improvising the division of labor in the middle of the window is how a good share of mistakes happen. Keep the old VPS powered on and serving, even after the switch. It is your safety net while DNS finishes propagating, and the cost of a few extra days is irrelevant next to the risk of shutting it down too early. ## Validation and rollback plan[](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#validacao-e-volta) Validation is not opening the home page and seeing that it loaded. It is walking through the paths that generate value and the ones that generate revenue, one by one, in the first hour after the cutover. * Login, sign-up and password recovery working end to end. * Payment flow tested with a real low-value transaction. * Transactional email landing in the inbox, not in spam. * Scheduled tasks running at the expected time on the new server. * Valid certificate on every domain and subdomain. * External integrations responding from the new IP address. * External monitoring confirming availability through the new address. * Backup of the dedicated server already running, with the first copy completed. * Response time compared against the old VPS baseline. The rollback plan needs to exist in writing before the cutover, not be improvised in the middle of it. It has three conditions: the old VPS stays powered on and untouched, the TTL stays low, and there is a defined point of no return, which is the moment new data has been written only to the dedicated server. Before that point, going back means reverting DNS and waiting. After it, going back means bringing the new data back, which is a lot more work. Make it clear to the team who decides on a rollback and based on what criterion. A simple rule works better than judgment in the heat of the moment: if the main service is not stable within a defined deadline, roll back, investigate calmly and reschedule. A second window costs less than an entire night trying to fix things in the dark. After two or three stable weeks, shut down the old VPS, keep a final copy of its state and update the environment documentation. If your diagnosis concluded that the VPS still has what it takes, staying on the [Ryzen VPS](https://streethosting.com.br/en/vps/ryzen) and reviewing capacity the following quarter is an equally valid decision. The guide on [when to use a dedicated server](https://streethosting.com.br/en/guides/infrastructure/when-to-use-a-dedicated-server) helps you revisit that point. In this guide * [The signs that it is time](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#sinais-de-limite) * [Confirm the diagnosis with numbers](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#confirmar-com-numeros) * [Inventory of what runs today](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#inventario) * [Prepare the dedicated server in parallel](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#preparar-em-paralelo) * [Move data and lower the TTL](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#mover-dados-e-dns) * [The cutover window](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#janela-de-corte) * [Validation and rollback plan](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server#validacao-e-volta) ## Frequently asked questions How do I know I need to move from a VPS to a dedicated server? The most reliable signs are steal time consistently above a few percent at peak hours, vCPU usage pinned at the ceiling for long stretches, high io wait during backups or data imports, and the combined cost of several VPS instances exceeding the price of a whole machine. One of these on its own does not decide it; repetition over weeks does. What is steal time and why does it matter? Steal time is the time your virtual machine wanted to use the processor and could not because the host was busy. It shows up in the corresponding column of top and htop. A consistently high value at peak hours means resource contention on the host, something no optimization inside your VPS can fix. How long does it take to migrate from VPS to dedicated? Preparation takes anywhere from a few days to two weeks, depending on how many services run today. The cutover window itself, when everything was rehearsed beforehand, usually comes down to minutes. What blows the schedule is discovering an unmapped dependency during the cutover, and that is exactly what the inventory prevents. Do I need to lower the DNS TTL before migrating? Yes. Lower the TTL of the records that will change to a short value at least 48 hours before the switch, so resolvers have already discarded the old value. Without that, some users keep landing on the old server for hours after the cutover. Can I go back to the VPS if the migration goes wrong? Yes, as long as you keep the old VPS powered on and untouched for a few days after the cutover and have not pointed new writes only at the destination. The rollback plan is simply reverting DNS, and it only works if the TTL is still low and the old environment is still standing. Next step See dedicated servers Exclusive hardware in São Paulo with NVMe and Anti-DDoS. [See dedicated servers](https://streethosting.com.br/en/dedicated) [See Ryzen VPS Ryzen 9 9950X VPS in São Paulo with root access, NVMe and gamer Anti-DDoS.](https://streethosting.com.br/en/vps/ryzen) ## Related guides [Infrastructure Advanced How to migrate a server to another provider with no downtime Switching hosts is scary because you might lose data or go offline. With preparation, testing and DNS under your control, the cutover happens with minimal interruption for your users. 3 min Read guide](https://streethosting.com.br/en/guides/infrastructure/migrate-server-without-downtime) [VPS Intermediate How to monitor VPS resources with htop and Netdata You only know you need a bigger plan once you can see the numbers. htop gives you a quick snapshot in the terminal, and Netdata gives you a full dashboard with CPU, RAM and disk history. 3 min Read guide](https://streethosting.com.br/en/guides/vps/monitor-vps-resources-htop-netdata) [Infrastructure Intermediate When to use a dedicated server: moving from a VPS to bare metal A dedicated server makes sense when predictable performance and physical isolation matter more than the flexibility of a VPS. The decision usually comes up with continuous workloads, compliance requirements, heavy I/O or specific licensing. With clear criteria, the migration lowers risk and avoids unnecessary cost. 4 min Read guide](https://streethosting.com.br/en/guides/infrastructure/when-to-use-a-dedicated-server) [← Back to the Guide Center](https://streethosting.com.br/en/guides)