Original guide

Cloud hosting deals print upgrade anytime. The provider's rules make your unused balance a discount on the way up and a refund on the way down

Answer first: Short answer: on the deals this site tracks you can change plan mid-term, and the deal pages will not tell you what happens to the money you have already paid. The pricing page answers the whole question in a single sentence, that you can upgrade and switch plans with no downtime, and the cloud page says upgrading takes only a few clicks. On both pages the words downgrade, proration, expiration and balance appear zero times each, and the only credit either page prints is a one-time AI credit rather than a billing credit. The provider's own knowledge base publishes the mechanics the deal pages omit. Moving up converts the unused balance of the term in progress into a discount on the price of the new plan, so no money comes back. Moving down prorates the unused portion of the higher tier and credits it back as a refund, drops the resources immediately and leaves the original expiry date exactly where it was. The same knowledge base records the limits: every billing cycle after the initial purchase is billed at the regular rate, an upgrade lets you choose only the current billing period or 12 months, and four changes are refused outright - Web or Cloud to VPS, anything to Agency, any upgrade on Cloud Enterprise, and an upgrade on a legacy OpenVZ VPS.

Published: 2026-10-11 00:10

What this guide adds

Every figure in this article is quoted from a page published by the provider, and each one is attributed in the sources list below. Two things are arithmetic rather than quoted, and both are labelled as derived where they appear: the half-term values of $191.76 and $671.76, which apply the provider's own printed 48-month promotional price and printed 48-month regular price for Cloud Startup to a 24-of-48-month remainder, and the 3.5x ratio between those two prices, which is simply the regular price divided by the promotional price. The provider's own example of a $50 balance against a $200 plan is quoted, not derived. Nothing here is estimated: where the provider publishes no figure - the valuation basis for the unused balance, the expiry date after an upgrade, which refund methods a downgrade offers - this article says so instead of filling it in.

What the deal pages actually print about changing plans

The pricing page asks and answers the plan-change question in one line: whether a plan can be changed if circumstances change, and the answer is that you can upgrade, that the options let you switch, and that this happens without downtime. The cloud page answers a similar question about upgrading to a cloud plan by saying it takes a few clicks in the dashboard. That is the entire treatment.

Counting the terms on the two pages, after flattening the text and lowercasing it: downgrade 0, prorat 0, expiration 0, expire 0, balance 0, regular rate 0, renewal price 0 and change your plan 0 on both pages. Upgrade appears once on each, and that single occurrence is the FAQ sentence above. Credit appears 9 times on the pricing page and once on the cloud page, and every one of those hits is an AI credit or a vibe coding credit described as a one-time gift, not a billing credit. Refund appears once on each page and is the footer link to the refund policy, not a statement about plan changes.

This matters for a buyer comparing deals because the deal page sells a long term at a promotional rate. If the tier turns out to be wrong, the only thing the page has told you is that changing it is easy. Whether the term you already paid for survives that change, and in what form, is not on the page at all.

The unused balance goes to two different places depending on direction

The provider's own billing documentation splits the answer by direction, and the two directions are not symmetrical.

Moving up, the wording is that your investment is kept by converting it to a discount on the upgrade price. Nothing is returned to you and nothing is added to a balance you could spend elsewhere; the value of the term you have not used yet can only be spent against a more expensive plan inside the same account.

Moving down, the wording is different in kind: the system calculates the price difference based on the unused portion of your higher-tier plan, and that prorated amount is credited back as a refund. A downgrade therefore returns value rather than only discounting it. The same page adds one condition that can reduce the refund to nothing: if the entire credit amount is automatically consumed by active account adjustments, the remaining added balance will be zero.

So the same unused days are worth a discount in one direction and a refund in the other, and in the second case the refund can be absorbed before it reaches you. Neither deal page mentions either rule.

The provider's own example, and the one number it never fixes

The provider publishes one worked example of the upgrade discount: if the remaining time on the current plan is worth $50 and the plan being upgraded to costs $200, the buyer obtains a $50 discount and pays $150. That example settles the arithmetic. It does not settle the valuation, because it never says what makes the remaining time worth $50. It could be what was paid for those days, or it could be the regular price of those days. The two readings are far apart.

Derived, from figures the provider prints on its own pages: the 48-month promotional price for Cloud Startup is printed as $383.52 against a printed regular price of $1,343.52, with a renewal rate printed as $25.99 per month. Applying those two prices to a remainder of half the term - 24 of 48 months - gives $191.76 if the unused time is valued at the promotional rate and $671.76 if it is valued at the regular price. The difference between the two readings is $480.00, and the regular price is 3.5x the promotional price.

That is the size of the unknown. The same multiplication applies to a downgrade refund, since the prorated amount is calculated from the unused portion of the higher tier. The provider prints both prices and prints the rule, but not the basis on which the rule is evaluated, so the discount on an upgrade and the refund on a downgrade are both indeterminate from published sources.

A downgrade keeps the expiry date and cuts the resources on the spot

Two rules on the downgrade page decide what a buyer actually experiences, and they pull in opposite directions.

The expiry date does not move: the expiration date of the current plan remains the same, and the downgrade applies immediately to the current billing period. The buyer does not get a shorter term and does not get a longer one. What does move immediately is the resource allocation - storage, bandwidth and website limits drop to the target plan's thresholds upon confirmation. So the account can lose resources the same day while the date it is paid up to stays where it was.

There is also a gate before the change is allowed at all: resource usage must not exceed the limits of the target plan, and if a downgrade to the selected plan is not possible, a notification explains the reason and the button is disabled. The change applies only to the selected plan, and other services in the account are unaffected.

For a deals buyer this is the concrete form of the risk. A long promotional term is cheap per month precisely because it is long; the escape route down is available, but it refunds the difference rather than shortening the commitment, and it removes the resources at the moment it is confirmed.

Every cycle after the first purchase is billed at the regular rate

The billing-cycle documentation carries the rule that matters most for anyone reading a discounted deal page: all billing cycles after initial purchase are billed at the regular rate. The promotional rate on the deal page is therefore attached to the initial purchase, and the plan-change routes re-price at the regular rate.

Two further constraints sit beside that rule. Switching from a monthly to a yearly hosting plan does not qualify for a free domain, so the bundled domain that a deal card badges is tied to the purchase route as well as to the term. And when upgrading hosting, the billing period offered is limited: the buyer can select either the current billing period or 12 months. The 48-month term that carried the lowest printed monthly rate is not one of the two options available at upgrade time.

The purchase documentation sets the baseline this rule modifies: the duration options are 1, 12, 24 or 48 months, and a longer duration gives a better per-month rate. The deal pages print the renewal rate beside the promotional rate - the pricing card prints a renewal figure and the cloud page prints a monthly figure described as applying when you renew - but neither page prints the rate that applies to a cycle change, which is the regular rate by the provider's own rule.

One more condition applies to changing the period with auto-renewal on: the updated cycle applies at the next renewal, and if the service is renewed manually before that date, the renewal can only use the current billing cycle. A pending renewal invoice must also be paid before the period can be changed, and the service must be active.

Upgrades take effect immediately, and the same page lists three other durations

The upgrade page states that upgrades take effect immediately. The page that explains what happens after an upgrade repeats that same sentence and then contradicts it three times over. It says the upgrade can take a few hours to complete. It says that if domain DNS records are updated, up to 24 hours should be allowed for propagation. And it says that where external domains point at the old IP address, web traffic is proxied to the new server for 7 days after the transfer completes, which is described as time to update DNS records before traffic is affected.

So one page carries four different time statements for the same event, and the deal pages carry none of them. The practical consequence is that immediate describes when the new resources and the new price take effect, not when the move is finished.

There is also a change of address to plan for. Upgrading from Web to Cloud hosting issues a new dedicated IP address, which the provider lists as requiring updates to FTP connections, remote database connections and any A record pointing a domain or subdomain at the plan. The new IP is found on the account details page after the upgrade completes.

The four plan changes the provider will not make for you

The published documentation names four changes that are not available, which is a different kind of limit from a price.

Web or Cloud to VPS: a Web or Cloud hosting plan cannot be upgraded directly to a VPS. A VPS plan must be purchased separately and the website content migrated manually. Anything to Agency: Agency hosting does not support direct upgrades either, so an Agency plan is bought separately and websites are moved with the Clone Website tool, which the provider says is available with Agency plans only, and the IP address changes during that move. Cloud Enterprise: upgrades are not available for the Cloud Enterprise plan at all, and the suggested alternative is migrating to a VPS. VPS internal resources: individual resources such as disk space or RAM cannot be upgraded separately, so the entire VPS plan must be upgraded.

The VPS page adds two more hard edges. KVM 8 cannot be upgraded because it is the highest tier available, so more capacity means buying additional VPS plans and sharing the load manually. OpenVZ VPS plans cannot be upgraded at all, and a migration from OpenVZ to KVM is required first - the same page that lists OpenVZ as legacy notes elsewhere that OpenVZ plans support monthly billing only. A VPS upgrade itself is quoted at up to 10 minutes, with files and configurations unchanged.

None of these four limits appears on either deal page, and each of them is the kind of decision a buyer makes after reading a plan comparison table rather than before.

Two plans in one account do not merge

The most expensive version of getting the plan change wrong is buying a second plan instead of changing the first, and the provider documents what that costs. Purchasing a new plan creates a separate service rather than extending an existing one. Hosting plans cannot be merged, and content is not moved automatically between them for free, which is why the provider recommends renewing the original plan instead.

The published escape routes are narrow. The existing plan can be renewed at any time while it is active, and a plan that expired less than 30 days ago can be reactivated, described as the fastest way to bring websites and email back online without manual work. If the new plan is eligible for a refund, a refund can be requested to the Hostinger balance and then used to renew the original.

If the new plan is kept instead, the content move is manual or paid, and the route depends on what the site is built with: WordPress uses an automated paid migration tool or a manual migration from backups; AI Builder in manual mode uses the automated paid tool, with the note that eCommerce data will not be migrated; AI Builder in agentic mode uses a free duplicate website feature; a custom PHP or HTML site is migrated manually from backups. The automated tools require the original plan to stay active. On top of the files, domains must be reconnected, mailboxes set up and email data migrated, and hosting configurations such as cron jobs and FTP accounts recreated by hand.

For a plan that expired less than 30 days ago, a backup of custom PHP and HTML website files and databases can be generated and downloaded. The documentation is explicit that AI Builder sites are not included in those backups and are permanently lost if the original plan is not renewed.

What is still not stated

Marking the unstated cells as unstated, rather than estimating them:

The valuation basis for the unused balance. The provider prints the rule and one worked example, but not whether remaining time is valued at what was paid or at the regular price. The derivation above shows the difference is 3.5x on the plan this site tracks.

The expiry date after an upgrade. The downgrade page states the rule explicitly - the expiration date remains the same - while the upgrade page and the after-upgrade page say nothing about it, so whether an upgrade extends, resets or preserves the paid-through date is not published.

Which refund methods a downgrade offers. The downgrade page says that if enabled, the billing cycle may be changed and a refund method selected, which makes the choice conditional without saying what enables it or what the options are.

Which active account adjustments can absorb a downgrade credit and reduce the added balance to zero. The condition is published; the list is not.

Whether the promotional rate can ever be recovered after a downgrade. The rule that all cycles after the initial purchase are billed at the regular rate suggests not, but no page states it as a rule for plan changes.

And no page publishes the discount available on any named upgrade path, so the only worked example of the mechanic remains the generic $50 against $200 illustration.

How to use this when comparing cloud hosting deals

The rules above change what a promotional term actually commits a buyer to, so they are worth checking before the term is chosen rather than after.

Pick the tier before committing to the longest term, because the long term is what buys the low printed rate and the change routes are re-priced at the regular rate by the provider's own rule. If a move up looks likely, budget it as a new purchase less a credit rather than as a refund, since the unused balance becomes a discount in that direction only. If a move down looks likely, expect the difference to be prorated and refunded while the expiry date stays where it is and the resources drop on confirmation.

Check resource usage against the lower tier before relying on the downgrade route, because the change is blocked with an explanation if usage exceeds the target plan. And treat the four refused changes as product decisions rather than price decisions: a VPS, an Agency plan and a Cloud Enterprise plan each sit outside the upgrade path, and a legacy OpenVZ VPS cannot be upgraded at all.

Finally, if a second plan has already been bought by mistake, the published order of remedies is to renew or reactivate the original first and refund the new plan to the account balance second, because the two plans will not merge and the content move is not free.