Shared hosting बनाम VPS: आपके लिए क्या बेहतर है?

Shared hosting बनाम VPS: संक्षिप्त उत्तर

Shared hosting बनाम VPS का अंतर केवल गति का नहीं है। Shared hosting में आप एक ऐसी मशीन पर अकाउंट किराए पर लेते हैं जिसे कोई और कॉन्फ़िगर करता है, पैच करता है और अन्य ग्राहकों के साथ साझा करता है। एक unmanaged VPS (virtual private server) में आप root access के साथ पूरा ऑपरेटिंग सिस्टम किराए पर लेते हैं, इसलिए आप जो चाहें इंस्टॉल कर सकते हैं और जो कुछ भी आप खराब करते हैं, उसे ठीक करने की जिम्मेदारी भी आपकी होती है।

तीन चीजें वास्तव में अलग हैं। या तो आपके पास root access होता है या नहीं। आपका memory allocation और गारंटी आपके प्लान पर निर्भर करती है। और जब आधी रात को सर्वर रिस्पॉन्स देना बंद कर देता है, तो या तो होस्ट उसे ठीक करता है या आप। फीचर ग्रिड की हर बात इन्हीं तीन बिंदुओं से निकलती है।

यदि आपकी साइट केवल पेजों, इमेज और एक कॉन्टैक्ट फॉर्म से बनी है, तो कई साइटों के लिए Shared hosting सही विकल्प है। यदि आपकी साइट को ऐसे प्रोग्राम की आवश्यकता है जो किसी के विजिट न करने पर भी चलता रहे, तो VPS चुनने से पहले यह जांच लें कि क्या आपका shared host persistent services को सपोर्ट करता है।

Shared hosting वास्तव में आपको क्या प्रदान करता है

एक Linux सर्वर एक साथ कई customer accounts चलाता है। प्रत्येक account एक home directory है जिसमें document root, एक database और एक mailbox होता है, और एक ही web server, आमतौर पर Apache या LiteSpeed, बॉक्स पर मौजूद हर site को serve करता है। आपको एक control panel मिलता है, और कुछ hosts shell prompt भी प्रदान करते हैं। आपको root access नहीं मिलता है, लेकिन कुछ providers आपकी home directory में software install करने, अनुमति प्राप्त ports और background services चलाने की सुविधा देते हैं।

कई shared hosts CloudLinux चलाते हैं, जो प्रत्येक account को उसके अपने lightweight container में रखता है। इसमें processor time, memory, disk I/O, processes की संख्या और entry processes की संख्या पर सीमाएं (caps) होती हैं। प्रत्येक सीमा के पूरा होने पर अलग तरह से विफलता (failure) होती है। processor या I/O सीमा तक पहुँचने से आपकी site धीमी गति से प्रतिक्रिया देती है; यह इसे तोड़ती नहीं है। memory सीमा या process सीमा तक पहुँचने पर आमतौर पर 500 और 503 errors दिखाई देते हैं। Apache के साथ, 508 Resource Limit Reached शीर्षक वाला error page entry-process सीमा के कारण आता है; LiteSpeed entry processes को अलग तरह से संभालता है। हर मामले में यह आपका अपना account है जो अपनी सीमा तक पहुँच रहा है, न कि कोई पड़ोसी जो आपका हिस्सा ले रहा है।

यह समझौता जानबूझकर किया गया है। आप नियंत्रण छोड़ देते हैं, और बदले में host kernel को patch करता है और समर्थित software का रखरखाव करता है; certificate renewal और backup schedules आपके plan पर निर्भर करते हैं। बहुत सारी sites के लिए यह एक अच्छा समझौता है।

VPS वास्तव में आपको क्या प्रदान करता है

VPS एक होस्ट सर्वर पर चलने वाली वर्चुअल मशीन है। KVM के अंतर्गत, आपका इंस्टेंस अपना स्वयं का kernel बूट करता है और उसके पास अपना IP address, अपना firewall और अपना init system होता है। root access वाले unmanaged Linux VPS पर, sudo काम करता है। Debian या Ubuntu इंस्टॉलेशन पर, apt install काम करता है। systemd के माध्यम से शुरू किया गया प्रोग्राम आपके लॉग आउट होने के बाद भी चलता रहता है, और उचित restart और boot कॉन्फ़िगरेशन के साथ, यह क्रैश होने के बाद फिर से शुरू हो जाता है और रीबूट के बाद वापस आ जाता है।

वही root access इस कारण से है कि मशीन की सुरक्षा आपकी जिम्मेदारी बन जाती है। कोई और इसकी निगरानी नहीं कर रहा है। VPS पर लोग जो चीजें चलाते हैं उनकी सीमा ठीक इसी कारण से व्यापक है: यह बॉक्स वह सब कुछ करता है जो एक Linux सर्वर कर सकता है।

अंतर 1: root access और यह क्या-क्या अनलॉक करता है

Root आपको ऑपरेटिंग सिस्टम पर पूर्ण नियंत्रण देता है। इसके साथ आप distribution से कोई भी package install कर सकते हैं, किसी भी port को bind कर सकते हैं, systemd unit लिख सकते हैं, मशीन पर मौजूद हर log को पढ़ सकते हैं और sysctl के साथ kernel settings बदल सकते हैं। इसके बिना, पैनल ही एकमात्र सीमा नहीं है: alwaysdata ad_install_pecl के साथ अतिरिक्त PHP extensions install करने की सुविधा देता है।

एक VPS पर आप हमेशा मशीन से पूछ सकते हैं कि कौन सा port listening मोड में है:

ss -ltnp

प्रत्येक socket पंक्ति एक TCP listener दिखाती है; process का विवरण आपकी अनुमतियों (permissions) पर निर्भर करता है, इसलिए यदि कोई service जिसे TCP पर listen करना था वह start होने में विफल रही है, तो वह पंक्ति गायब दिखेगी। Shared hosting पर, socket जानकारी तक पहुँच और अपने स्वयं के listeners चलाने की अनुमति प्रदाता (provider) पर निर्भर करती है, भले ही host port 80 और 443 को नियंत्रित करता हो।

अंतर 2: आवंटित मेमोरी बनाम उधार ली गई मेमोरी

Shared hosting इस धारणा पर बेची जाती है कि कुछ ही accounts एक ही समय पर व्यस्त होते हैं। मशीन की मेमोरी एक pool की तरह होती है, और आपका हिस्सा एक reservation के बजाय केवल एक limit है। CloudLinux पर, physical-memory limit तक पहुँचने पर processes kill हो जाती हैं और visitors को 500 या 503 error मिल सकता है।

VPS पर, free -m आपके guest को दिखाई देने वाली मेमोरी की रिपोर्ट करता है, न कि यह इस बात का प्रमाण है कि physical-memory का एक हिस्सा आपके लिए स्थायी रूप से आरक्षित है। एक host 'ballooning' के माध्यम से guest memory को वापस ले सकता है; आपके plan के लिए provider की resource guarantees यह तय करती हैं कि क्या इसकी अनुमति है।

Processor time, shared-CPU VPS plans पर एक और साझा संसाधन है, और आप स्वयं 'steal time' को माप सकते हैं:

vmstat 1 5

st column 'steal time' को दर्शाता है: वह समय जब आपका virtual processor चलने के लिए तैयार था, लेकिन physical core किसी अन्य guest को दिया गया था। ऐसा कोई सार्वभौमिक सामान्य प्रतिशत या threshold नहीं है जो oversubscription को सिद्ध करे; निरंतर बना रहने वाला 'steal time' वह आंकड़ा है जिसे आप support ticket में उद्धृत कर सकते हैं। vmstat को अपनी सामान्य readings के लिए संबंधित /proc files तक पहुँच की आवश्यकता होती है, न कि root access की, और एक shared host इस दृश्यता (visibility) को प्रतिबंधित कर सकता है। Storage भी जाँचने के लिए एक महत्वपूर्ण संसाधन है, इसीलिए VPS plan के पीछे की disk type मायने रखती है, और इसीलिए sales page पर भरोसा करने के बजाय पहले सप्ताह में स्वयं एक नए VPS को मापना उचित रहता है।

अंतर 3: खराबी आने पर जिम्मेदारी किसकी है

Shared hosting पर होस्टिंग प्रदाता ऑपरेटिंग सिस्टम, वेब सर्वर और समर्थित PHP बिल्ड्स का प्रबंधन करता है; सर्टिफिकेट और बैकअप कवरेज आपके प्लान पर निर्भर करते हैं। जब मशीन रिस्पॉन्स देना बंद कर देती है, तो आप एक टिकट खोलते हैं; प्रतिक्रिया होस्ट के सपोर्ट अरेंजमेंट पर निर्भर करती है। इसकी कीमत उसी नियम का दूसरा पहलू है: समर्थित वातावरण के बाहर का कोई भी सॉफ्टवेयर होस्ट की इंस्टॉलेशन और सर्विस नीतियों के अनुरूप होना चाहिए।

एक unmanaged VPS पर प्रदाता केवल हाइपरवाइजर, नेटवर्क और पावर का मालिक होता है। कर्नेल से ऊपर की हर चीज आपकी जिम्मेदारी है। सुरक्षा अपडेट, फायरवाल, बैकअप, सर्टिफिकेट रिन्यूअल और मॉनिटरिंग का सारा काम आपको करना होगा, और सपोर्ट टीम आपके वेब सर्वर कॉन्फ़िगरेशन को डीबग करने के लिए लॉग इन नहीं करेगी। पहले दिन से ही इसकी योजना बनाएं: नए VPS पर शुरुआती दस मिनट, फिर एक ऐसी फायरवाल जिसे आप समझते हों, स्वचालित सुरक्षा अपडेट और ऐसे बैकअप जिन्हें आपने कम से कम एक बार रिस्टोर करके देखा हो।

जब shared hosting सही विकल्प हो

एक brochure site इसका सबसे स्पष्ट उदाहरण है: कुछ pages, images, एक contact form, शायद caching plugin के साथ WordPress, और plan की resource limits के भीतर traffic। इसमें कोई background jobs नहीं होतीं। कोई असामान्य runtime नहीं होता। ऐसी कोई चीज़ नहीं जिसे requests के बीच memory में रहना पड़े। Shared hosting ऐसी site के लिए उपयुक्त है और सर्वर के रखरखाव का काम उन लोगों को सौंप देती है जो इसे पूर्णकालिक करते हैं; कीमतों की तुलना करें क्योंकि यह हर VPS से सस्ता नहीं होता। इसे VPS पर ले जाने से कोई लाभ नहीं मिलता और एक ऐसा काम बढ़ जाता है जो पहले आपके पास नहीं था।

एक दूसरा मामला भी है जिस पर कम ध्यान दिया जाता है। यदि आपकी ओर से कोई भी log file पढ़ने या apt upgrade चलाने का इच्छुक नहीं है, तो shared hosting एक सुरक्षित विकल्प है। एक unpatched VPS जिसमें database port खुला हो, एक ऐसे shared account से कहीं अधिक बुरा है जिसे कोई पेशेवर व्यक्ति अद्यतित (current) रखता है। Control केवल तभी एक लाभ है जब कोई उसका उपयोग करे।

संकेत 1: आपको एक ऐसे प्रोग्राम की आवश्यकता है जो लगातार चलता रहे

Daemon एक ऐसा प्रोग्राम है जो memory में रहता है और काम का इंतज़ार करता है: जैसे API, chat bot, queue worker, या game server। Shared hosting के नियम अलग होते हैं: DreamHost shared plans पर persistent processes की अनुमति नहीं देता, जबकि alwaysdata भुगतान वाले plans पर supervised custom services की सुविधा देता है।

VPS पर वही प्रोग्राम एक systemd unit बन जाता है:

sudo systemctl enable --now myapp
systemctl status myapp

systemctl status को process ID के साथ Active: active (running) प्रिंट करना चाहिए। यदि यह Active: failed (Result: exit-code) प्रिंट करता है, तो इसका कारण journalctl -u myapp -n 50 में होता है, जो प्रोग्राम के रुकने के समय उसके स्वयं के output को दिखाता है। unit file में Restart=always इसे crash के बाद वापस लाता है, और enable इसे reboot के बाद वापस लाता है। systemd services और timers लिखना पहली ऐसी VPS skill है जिसे ठीक से सीखना सार्थक है।

संकेत 2: आपको ऐसे रनटाइम की आवश्यकता है जो पैनल में उपलब्ध नहीं है

पैनल आपको एक सूची प्रदान करता है। यदि आपके एप्लिकेशन को उस सूची से बाहर के किसी भाषा संस्करण, किसी ऐसी लाइब्रेरी जिसे कंपाइल करने की आवश्यकता हो, ffmpeg, किसी हेडलेस ब्राउज़र, या ऐसे डेटाबेस की आवश्यकता है जो पैनल में उपलब्ध नहीं है (cPanel में MySQL और, जहाँ होस्ट इसे चालू करता है, PostgreSQL शामिल है), तो प्रदाता के इंस्टॉलेशन नियमों की जाँच करें। अपनी होम डायरेक्टरी में सॉफ़्टवेयर इंस्टॉल करने के लिए हमेशा root एक्सेस की आवश्यकता नहीं होती है: DreamHost साझा सर्वर पर zlib और कस्टम Python संस्करण को कंपाइल करने के दस्तावेज़ प्रदान करता है।

VPS पर आप इसे apt install के साथ इंस्टॉल करते हैं, या आप इसे कंटेनर में चलाते हैं और होस्ट को साफ रखते हैं। VPS पर Docker Compose सामान्य रास्ता है, विशेषकर तब जब एप्लिकेशन में एक से अधिक घटक शामिल हों।

संकेत 3: आपका cron job समय पर चलना चाहिए

Shared hosts एक फॉर्म के माध्यम से cron jobs स्वीकार करते हैं, और host अपनी ओर से न्यूनतम अंतराल (minimum interval) निर्धारित कर सकता है। CloudLinux पर, जो job account की processor limit तक पहुँचता है, उसे kill करने के बजाय धीमा कर दिया जाता है। इसलिए, जब अगला job शुरू होने का समय होता है, तब भी पिछला job चल रहा हो सकता है। यदि account पहले से ही अपनी process cap पर है, तो job कोई नई process शुरू ही नहीं कर पाएगा। आप इसमें से कुछ चीजें देख सकते हैं: cPanel की Cron Email सेटिंग आपको प्रत्येक job का output mail करती है, और जिन CloudLinux hosts पर यह सुविधा है, वहाँ panel में मौजूद Resource Usage पेज उस limit का नाम बताता है जिसे account ने पार किया है और faults की गिनती दिखाता है। system logs तक पहुँच और limits बढ़ाने का अधिकार host के पास ही रहता है, लेकिन कुछ providers task logs में start और end times दिखाते हैं।

एक VPS पर crontab -e उन schedules को स्वीकार करता है जो installed cron implementation द्वारा समर्थित हैं, और एक systemd timer इससे भी बेहतर है:

systemctl list-timers
journalctl -u cron -n 20

list-timers memory में मौजूद timers के लिए अगले और पिछले trigger times को print करता है, न कि उनकी services के exit results को; cron journal installed cron service और logging configuration पर निर्भर करता है। जब कोई job नहीं चलता है, तो उसकी service status और logs की जाँच करें ताकि यह पता चल सके कि वह कभी शुरू ही नहीं हुआ या शुरू होकर fail हो गया। scheduled task को debug करने में यही अंतर सबसे महत्वपूर्ण है।

संकेत 4: आपके पड़ोसी आपकी response time बढ़ा रहे हैं

यह लक्षण विशिष्ट है। आपके कोड में बिना किसी बदलाव के, वही पेज रात में जल्दी और शाम सात बजे धीरे लोड होता है। किसी और को दोष देने से पहले इसे अपनी मशीन से मापें:

for i in $(seq 1 20); do curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/; sleep 5; done

time_starttransfer रिस्पॉन्स के पहले बाइट तक का समय है, जिसे सेकंड में मापा जाता है। यदि बीस संख्याएँ एक-दूसरे के करीब हैं, तो यह स्थिर समय को दर्शाता है, न कि यह कि समस्या सर्वर, कोड या डेटाबेस में है। यदि वे सुबह 3 बजे स्थिर रहती हैं और पीक आवर्स के दौरान कई सौ मिलीसेकंड तक बदल जाती हैं, तो पड़ोसी अकाउंट्स को दोष देने से पहले अकाउंट रिसोर्स उपयोग, रिक्वेस्ट वॉल्यूम और सर्वर लॉग्स की तुलना करें। इन टाइमिंग्स में कनेक्शन सेटअप और सर्वर प्रोसेसिंग शामिल हैं, इसलिए ये अपने आप में समस्या का कारण स्पष्ट नहीं करती हैं।

मूव की वास्तविक लागत

ये 4 नवंबर, 2026 को जाँचे गए विज्ञापित उदाहरण हैं, न कि पूरी श्रेणी का औसत या सबसे छोटे उपलब्ध प्लान। Shared, 4 GB VPS और managed उदाहरण DreamHost के Web Hosting Launch, Stack 4 और Managed VPS Business के वार्षिक बिलिंग प्लान हैं; 1 GiB VPS, DigitalOcean का नियमित Basic Droplet है जो मासिक कैप पर आधारित है। खरीदने से पहले वर्तमान मूल्य की जाँच करें।

[
  {
    "plan": "Shared hosting, DreamHost",
    "first_term_usd": 2.89,
    "renewal_usd": 10.99
  },
  {
    "plan": "VPS, 1 vCPU 1 GiB, DigitalOcean",
    "first_term_usd": 6,
    "renewal_usd": 6
  },
  {
    "plan": "VPS, 2 vCPU 4 GB, DreamHost",
    "first_term_usd": 6.99,
    "renewal_usd": 11.99
  },
  {
    "plan": "Managed VPS, 2 cores 2 GB, DreamHost",
    "first_term_usd": 13.75,
    "renewal_usd": 31.99
  }
]

मुख्य अंतर 2.89 से 6 अमेरिकी डॉलर प्रति माह के बीच है, और केवल यह संख्या ही सब कुछ तय नहीं करती। Shared उदाहरण के लिए एक साल का भुगतान पहले करना होता है और यह 10.99 डॉलर प्रति माह पर रिन्यू होता है। रिन्यूअल की तुलना रिन्यूअल से करें तो स्थिति बदल जाती है: Shared अकाउंट के लिए 10.99 डॉलर बनाम एंट्री VPS के लिए 6 डॉलर। DigitalOcean के दोनों आंकड़े समान हैं क्योंकि इस उदाहरण में कोई शुरुआती छूट नहीं है।

उस तुलना को सावधानी से करें, क्योंकि आकार समान नहीं हैं। एक 1 vCPU, 1 GB VPS वेब सर्वर और डेटाबेस को एक छोटे बॉक्स पर चलाता है, जो वास्तविक ट्रैफिक आने पर WordPress के लिए कम पड़ सकता है। 2 vCPU, 4 GB वाला उदाहरण 11.99 डॉलर प्रति माह पर रिन्यू होता है, लेकिन shared-account की सीमाएं और VPS की क्षमता सीधे तौर पर एक-दूसरे के बराबर नहीं हैं। इन उदाहरणों में, shared hosting की तुलना में इसका रिन्यूअल प्रीमियम एक डॉलर प्रति माह है।

बड़ी लागत कभी भी इनवॉइस पर नहीं दिखती। एक VPS सेटअप में एक घंटा, अपडेट के लिए हर महीने कुछ मिनट, और पहली बार कुछ खराब होने पर आपकी एक पूरी शाम खर्च होती है। इसकी कीमत अपने प्रति घंटा रेट के हिसाब से जोड़ें तो यह अंतर जल्दी ही खत्म हो जाता है। व्यावहारिक रूप से VPS की लागत में आकारों का अधिक विस्तार से विवरण दिया गया है।

ट्रैफिक खोए बिना shared hosting से साइट को स्थानांतरित करना

1. एक दिन पहले, domain के लिए DNS (domain name system) TTL (time to live) को घटाकर 300 seconds कर दें, और switch करने से पहले पुराने TTL को expire होने दें; local caches को update होने में अधिक समय लग सकता है।
2. नया server तैयार करें और DNS को छेड़ने से पहले site को उसके IP address पर चलाकर देखें।
3. files को copy करें, फिर database का dump लें और उसे नए box पर restore करें।
4. अपने laptop की hosts file के माध्यम से test करें, जो domain को केवल आपकी machine के लिए नए IP पर point करती है।
5. A record बदलने से पहले DNS validation या किसी मौजूदा valid certificate का उपयोग करके नए server पर TLS (transport layer security) certificate जारी करें, और shared account को एक सप्ताह तक active रखें।

dig example.com A +noall +answer
rsync -avz ~/public_html/ deploy@203.0.113.10:/srv/www/example.com/
mysqldump --single-transaction -u dbuser -p dbname > site.sql

dig अपने उत्तर के दूसरे column में TTL print करता है, इसलिए आप switch करने से पहले confirm कर सकते हैं कि कम value live है या नहीं। --single-transaction InnoDB tables को lock किए बिना उनका एक consistent snapshot लेता है; nontransactional tables और concurrent schema changes के लिए अलग से सावधानी बरतने की आवश्यकता होती है, और बाद के orders उस snapshot में शामिल नहीं होते हैं। नए server पर, उसी दिन certificates को काम करने योग्य बनाएँ: Ubuntu पर nginx के साथ Let's Encrypt का उपयोग करके, एक बार जब DNS record box पर point करने लगे, तो इसमें कुछ ही मिनट लगते हैं।

जिम्मेदारी के बिना संसाधन

यदि चार संकेत आपकी साइट पर लागू होते हैं लेकिन आप रखरखाव नहीं करना चाहते, तो मध्यम विकल्प एक managed VPS है। प्रदाता सहमत रखरखाव का कार्य संभालता है, लेकिन root access और प्रबंधन का दायरा प्लान पर निर्भर करता है; DreamHost का managed VPS root access प्रदान नहीं करता है। ऊपर दिया गया चार्ट इसके 2 GB managed उदाहरण की कीमत 31.99 डॉलर और 4 GB unmanaged उदाहरण की कीमत 11.99 डॉलर दर्शाता है, इसलिए यह समान आकार की तुलना नहीं है। यह अंतर उस समय के लिए है जब रात में सर्वर काम करना बंद कर दे और कोई और उसे ठीक करे।

Managed बनाम unmanaged VPS का निर्णय यदि यह आपके लिए उपयुक्त है, तो अगला सही लेख है। यदि आप पहले से ही एक व्यस्त VPS चला रहे हैं और peak hours के दौरान भी steal time अधिक है, तो इसके बाद का अगला कदम बिना किसी पड़ोसी वाला एक dedicated server है।

FAQ

क्या VPS, shared hosting से तेज़ होता है?

हमेशा नहीं। एक शांत shared server, single WordPress page के लिए 1 vCPU वाले VPS से बेहतर प्रदर्शन कर सकता है। आवंटित memory, CPU contention को पूरी तरह खत्म नहीं करती: shared-CPU VPS पर, पड़ोसी instances response time को प्रभावित कर सकते हैं, और memory की गारंटी provider पर निर्भर करती है। यदि आपके pages सुबह 3 बजे और शाम 7 बजे, दोनों समय धीमे हैं, तो code, database queries और hosting resource limits की जाँच करें; दिन का समय कारण निर्धारित नहीं करता है।

क्या मैं shared hosting पर Node.js या Python app चला सकता हूँ?

कभी-कभी, provider की सीमाओं के भीतर। कुछ panels Passenger के माध्यम से आपके लिए application start करते हैं, और request आने पर यह चलती है। host का ports 80 और 443 पर स्वामित्व अन्य अनुमत listeners को नहीं रोकता: alwaysdata अपने Public Cloud पर IPv6 के माध्यम से ports 8300 से 8499 पर custom services की अनुमति देता है। Persistent-process के नियम भी host के अनुसार अलग-अलग होते हैं, इसलिए bot, queue worker या websocket server के लिए ऐसे plan की आवश्यकता होती है जो स्पष्ट रूप से इसका समर्थन करता हो, न कि अनिवार्य रूप से VPS की।

क्या VPS चलाने के लिए मुझे Linux जानना आवश्यक है?

unmanaged VPS के लिए, हाँ। आपको SSH keys, firewall, updates, backups और logs पढ़ने की आदत की आवश्यकता होगी। शुरुआती setup के लिए एक घंटा और उसके बाद हर महीने कुछ मिनट का समय निकालें। यदि आप यह काम नहीं करना चाहते हैं, तो एक managed plan सहमत रखरखाव की जिम्मेदारी provider को सौंप देता है, जो managed बनाम unmanaged VPS hosting में कवर किया गया समझौता है।

क्या shared hosting से VPS पर जाते समय मेरी साइट down हो जाएगी?

DNS TTL को कम करना और दोनों accounts को चालू रखना downtime से बचने में मदद करता है, लेकिन यह निर्बाध स्थानांतरण की गारंटी नहीं देता है। TTL को एक दिन पहले 300 seconds पर सेट करें और पिछले TTL को expire होने दें, files और database को copy करें, अपने laptop की hosts file के माध्यम से नए server का परीक्षण करें, और फिर A record बदलें। बदलाव के दौरान कुछ visitors पुराने server तक पहुँचते हैं और कुछ नए तक, और caches को update होने में पाँच मिनट से अधिक का समय लग सकता है, इसलिए shared account को एक सप्ताह तक चालू रखें। अंतिम database dump और restore के लिए writes को pause करें, और पुरानी साइट को read-only रखें या उसकी requests को नए server पर भेजें ताकि बाद के writes खो न जाएं।