Paano Maglipat ng Web Hosting (Migration) nang Walang Data Loss? Kumpletong Gabay 2025

Ang server migration o paglipat ng hosting ay ang sistematikong proseso ng paglilipat ng mga file ng website, database, email accounts, DNS records, at configuration ng aplikasyon mula sa lumang server papunta sa bagong server. Ang pangunahing sikreto para makapaglipat ng site nang walang data loss ay ganito: kumuha muna ng kumpletong backup, ihanda ang bagong server na may kapareho o mas bagong software versions, ilipat ang files at database, magsagawa ng test gamit ang hosts file o temporary URL, baguhin ang DNS routing gamit ang mababang TTL value, at pagkatapos ng migration ay i-monitor ang logs, forms, payment gateways, email deliverability, at SEO signals.

Ang server migration ay hindi simpleng copy-paste na trabaho. Lalo na para sa mga site na gumagamit ng WordPress, WooCommerce, Laravel, custom PHP applications, high-traffic news websites, o corporate email, ang maling paglipat ay maaaring magresulta sa nawalang orders, corrupted na mga special character (gaya ng Ñ o accented letters), 500 internal server errors, SSL warnings, email interruption, at pagbaba ng visibility sa search engines. Dahil dito, kailangan isagawa ang migration plan na may teknikal na checklist at rollback scenario.

Sa gabay na ito, tatalakayin natin nang sunud-sunod kung paano magsagawa ng hosting o server change na naaayon sa 2026 SEO at performance standards. Sasaklawin din natin ang iba't ibang senaryo tulad ng cPanel, Plesk, VPS, cloud server, at manual migration; magbabahagi kami ng mga praktikal na rekomendasyon para sa DNS propagation time, backup coverage, database compatibility, SSL installation, at post-migration SEO checks.

Kailan Kailangang Maglipat ng Server?

Ang pangangailangang ilipat ang isang website sa bagong server ay kadalasang nagmumula sa performance, seguridad, gastos, o scalability. Halimbawa, ang isang corporate site na may 5,000 monthly visitors ay maaaring tumakbo nang maayos sa shared hosting, pero ang isang e-commerce site na may 20,000 daily visitors ay maaaring makaranas ng CPU limit, mabagal na database queries, at timeout issues sa checkout page. Sa puntong ito, mas mainam nang pumili ng mas malakas na hosting package, VPS, o cloud infrastructure.

Ang mga karaniwang senyales na nagsasaad na kailangan nang mag-migrate ay ang mga sumusunod:

• Ang page load time ay lumalampas na sa 3 segundo at bumabagsak ang Core Web Vitals metrics.
• Madalas na napupuno ang CPU, RAM, inode, o disk usage limits sa hosting panel.
• Kailangan na ng mas bagong bersyon ng PHP, MySQL, MariaDB, Node.js, o ionCube.
• Madalas na nagkakaroon ng isyu sa SSL renewal, email delivery, o DNS management.
• Hindi na sapat ang kalidad ng suporta, backup, o security level ng kasalukuyang provider.
• Biglaang pagtaas ng site traffic tuwing may campaign, ads, o peak season.

Kung lumalaki na ang iyong site at papalapit na sa limitasyon ng kasalukuyang package, mas ligtas na gumawa ng kontroladong migration plan kaysa magmadali sa oras ng krisis. Depende sa iyong pangangailangan, maaari mong ikumpara ang web hosting packages, VPS server solutions, o corporate hosting para mapili ang tamang imprastraktura.

Paghahanda Bago ang Migration: Ang Pinaka-Kritikal na Yugto

Karamihan sa mga bigong migration project na may data loss ay hindi dahil sa aktuwal na paglilipat, kundi dahil sa kakulangan sa paghahanda. Bago simulan ang migration, dapat gumawa ng imbentaryo ng kasalukuyang site, at linawin kung aling data ang ililipat at aling mga serbisyo ang sensitibo sa downtime.

1. Gumawa ng Site Inventory

Ang unang hakbang ay ang paggawa ng teknikal na mapa ng website. Dapat itala ang ginagamit na CMS o framework, PHP version, uri ng database, disk size, email accounts, cron jobs, DNS records, SSL certificate, custom redirects, at third-party integrations. Halimbawa, sa isang WordPress site, hindi sapat na ilipat lang ang wp-content folder; kailangan ding suriin ang .htaccess rules, wp-config.php settings, database table prefixes, cache plugins, at media files.

Sa isang e-commerce site, dapat hiwalay na suriin ang payment gateway, shipping integration, stock synchronization, ERP connection, SMTP service, at webhook URLs. Kung pagkatapos ng migration ay walang pumapasok na orders, ang problema ay kadalasang wala sa file transfer, kundi sa isang nakalimutang API IP restriction o security rule na naka-hardcode sa lumang server.

2. Kumuha at I-verify ang Kumpletong Backup

Sa server migration, hindi sapat ang kumuha lang ng backup; dapat itong ma-verify na ito ay maaaring i-restore. Ang kumpletong backup ay dapat sumaklaw sa mga sumusunod na bahagi:

• Website files: public_html, application folders, upload directories, theme at plugin files.
• Mga Database: MySQL, MariaDB, PostgreSQL, o iba pang database na ginagamit ng aplikasyon.
• Email data: mailboxes, forwarders, filters, autoresponder settings.
• DNS records: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC records.
• Mga Configuration: .htaccess, nginx.conf, php.ini, cron jobs, environment files.
• SSL certificates at custom security rules.

Bilang praktikal na approach, kumuha ng hindi bababa sa dalawang kopya ng backup bago ang migration: ang isa ay itago sa kasalukuyang server, at ang isa ay sa ibang lokasyon. Para sa malalaking site, maaaring gumamit ng rsync para sa file backup, at mysqldump o panel backup tools para sa database. Para sa mga database na lampas 10 GB, mas ligtas ang compressed at split backups kaysa sa iisang dump file.

3. Ibaba ang DNS TTL Value nang Maaga

Para mapabilis ang DNS propagation, magandang practice na ibaba ang TTL value 24 oras bago ang aktwal na migration. Halimbawa, kung ang TTL value ay 14400 segundo, maaaring may mga user na patuloy na pumupunta sa lumang server nang ilang oras. Sa pamamagitan ng pagbaba nito sa 300 segundo bago ang migration, nagiging mas kontrolado ang DNS transition. Pagkatapos makumpleto at ma-verify ang lahat, maaaring itaas muli ang TTL sa 3600 o 14400 segundo.

Ang maayos na pamamahala ng DNS ng iyong domain ay direktang nakakaapekto sa tagumpay ng migration. Para sa domain at DNS configuration, maaari mong suriin ang mga gabay sa domain lookup at domain name management.

Paghahambing ng mga Paraan ng Server Migration

Ang pinaka-tamang paraan ng migration ay hindi pare-pareho para sa bawat site. Ang isang maliit na corporate site ay madaling mailipat gamit ang control panel, samantalang ang isang high-traffic e-commerce site ay maaaring mangailangan ng incremental synchronization at maintenance mode.

Kapag pumipili ng bagong imprastraktura, nakakaligaw kung titingnan lamang ang disk space. Ang mga pamantayan tulad ng PHP worker count, CPU core, RAM, NVMe disk, backup frequency, lokasyon ng data center, suporta sa LiteSpeed o Nginx, WAF, at DDoS protection ay tumutukoy rin sa performance. Kaya naman, ang paglipat sa pinakamurang package nang walang pagsusuri ng pangangailangan ay maaaring magdulot ng panibagong pangangailangang mag-migrate sa maikling panahon.

Paano Gawin ang Server Migration nang Sunud-sunod?

Hakbang 1: Ihanda ang Bagong Server

Sa bagong server, dapat mai-install ang operating system, web server, PHP version, database service, at mga kinakailangang modules. Para sa WordPress, inirerekomenda ang PHP 8.2 o 8.3, pinakabagong MariaDB, OPcache, at tamang memory_limit value. Para sa mga frameworks tulad ng Laravel, kailangang hiwalay pang i-set ang Composer, cron, queue worker, at storage permissions. Kung wala sa bagong server ang mga PHP extensions na tumatakbo sa luma, maaaring magkaroon ng white screen o 500 error pagkatapos ng paglipat.

Sa aspeto ng seguridad, dapat i-configure ang SSH port policy, malalakas na passwords, firewall, malware scanning, at automatic updates. Mas madaling itatag ang security baseline habang bago pa at walang laman ang server kaysa makialam pagkatapos. Kung kailangan mo ng SSL, tiyaking isama ang paksa ng SSL certificate installation sa migration plan.

Hakbang 2: Ilipat ang mga File

Para sa file transfer, maaaring gumamit ng FTP, SFTP, SSH, rsync, o panel backup batay sa laki ng site. Sa maliliit na site, sapat na ang gumawa ng compressed archive at i-extract ito sa bagong server. Sa malalaking site naman, inirerekomenda ang pagkuha ng unang kopya gamit ang rsync at muling pag-sync bago ang DNS change. Ang paraang ito ay nakakatipid ng oras, lalo na sa mga site na patuloy na nagbabago ang upload folder.

Pagkatapos ng file transfer, suriin ang mga pahintulot. Sa pangkalahatan, ang mga folder ay tumatakbo sa 755 na pahintulot, at ang mga file sa 644; ngunit maaaring magkaiba ang pangangailangan ng bawat aplikasyon. Ang mga sensitibong file tulad ng wp-config.php, .env, o katulad nito ay hindi dapat nababasa ng lahat. Tiyakin ding nakopya ang mga nakatagong file, tulad ng .htaccess at .user.ini.

Hakbang 3: Ilipat ang Database

Ang database transfer ang pinaka-sensitibong bahagi para maiwasan ang data loss. Una, kumuha ng dump mula sa lumang server, pagkatapos ay lumikha ng database at user sa bagong server. Ang character set ay dapat itakda sa utf8mb4 hangga't maaari. Upang hindi masira ang mga espesyal na karakter, panatilihin ang parehong collation structure sa panahon ng export at import.

Para sa mga site na bumubuo ng real-time na data tulad ng WooCommerce o membership system, maaaring gumamit ng maintenance mode sa panahon ng paglipat. Kung hindi, sa oras ng DNS propagation, maaaring may mga user na nagsusulat ng data sa lumang server, at ang iba ay sa bago. Lumilikha ito ng hindi pagkakatugma sa orders, comments, form entries, o membership details. Sa mga kritikal na site, ang huling database dump ay dapat gawin pagkatapos i-activate ang maintenance mode.

Hakbang 4: I-update ang mga Configuration File

Ang pangalan ng database, username, password, host information, at file paths ay dapat ayusin ayon sa bagong server. Para sa WordPress, suriin ang wp-config.php; para sa Laravel, ang .env; para sa custom applications, ang config.php o katulad na mga file. Kung mananatili ang absolute file paths, IP address, SMTP settings, o cache directories ng lumang server, maaaring magmukhang bukas ang site ngunit bumubuo ito ng mga error sa background.

Dapat ding i-adjust ang PHP memory_limit, upload_max_filesize, post_max_size, at max_execution_time values ayon sa pangangailangan ng iyong aplikasyon. Halimbawa, kung ang isang admin panel ay nag-a-upload ng 200 MB na mga imahe ng produkto, at ang upload limit ay nanatiling 32 MB, kahit matagumpay ang migration, hindi makakapagpatuloy ang operasyon.

Hakbang 5: Mag-Test Bago Palitan ang DNS

Ang pinaka-ligtas na practice sa migration ay ang pag-test ng site sa bagong server bago baguhin ang DNS. Para magawa ito, maaari mong i-map ang iyong domain name sa IP address ng bagong server sa hosts file ng iyong computer. Sa ganitong paraan, habang nakikita pa ng mga bisita ang lumang server, ikaw ay nagte-test sa bagong server gamit ang tunay na domain name.

Ang test list ay dapat sumaklaw sa mga sumusunod na pagsusuri:

• Nagbubukas ba ang homepage, category, product, blog, at contact pages?
• Gumagana ba ang form submission, member login, password reset, at payment flow?
• Kumpleto bang naglo-load ang mga imahe, CSS, at JavaScript files?
• Nagbubukas ba ang admin panel nang walang error?
• Naka-install ba ang SSL certificate para sa tamang domain name?
• Mayroon bang 404, 500, mixed content, o redirect loop errors?
• Tama ba ang robots.txt, sitemap.xml, at canonical tags?

Hakbang 6: I-install ang SSL Certificate

Sa mga modernong website, ang SSL ay hindi lamang para sa seguridad, kundi isang pangangailangan na rin para sa SEO at tiwala ng gumagamit. Kung babaguhin ang DNS nang hindi naka-install ang SSL sa bagong server, maaaring makakita ang mga user ng babalang "Not Secure". Kaya naman, bago o kasabay ng DNS transition, dapat handa na ang SSL certificate. Ang mga libreng certificate tulad ng Let's Encrypt ay maaaring sapat na para sa maraming site; para sa mga corporate project na tumatanggap ng bayad, maaaring pumili ng mga opsyon sa SSL na may mas mataas na antas ng validation.

Pagkatapos ng SSL, tiyaking ang mga HTTP address ay nire-redirect sa HTTPS gamit ang 301, walang mixed content error, at ang mga HTTPS URL ang nasa sitemap. Para sa mga produkto at opsyon sa pag-install ng SSL, maaari mong tingnan ang pahina ng SSL certificates.

Hakbang 7: Palitan ang DNS Records

Pagkatapos ng matagumpay na mga pagsubok, sa panig ng DNS, ang A record ay itinuturo sa IP address ng bagong server. Kung ang serbisyo ng email ay inililipat din sa parehong server, dapat i-update ang MX, SPF, DKIM, at DMARC records. Kung mananatili ang email sa ibang provider, hindi dapat galawin ang MX records. Isa sa mga pinakamadalas na pagkakamali ay ang aksidenteng pagbabago sa email records habang ang balak lang ay ilipat ang website, na nagreresulta sa pagkaputol ng mail traffic.

Ang DNS propagation ay karaniwang tumatagal mula sa ilang minuto hanggang 24 na oras. Kung ibinaba ang TTL nang maaga, karamihan sa mga user ay makakarating sa bagong server sa maikling panahon. Sa prosesong ito, huwag agad isara ang lumang server. Isang ligtas na practice na panatilihin itong accessible nang hindi bababa sa 48 oras, at kung maaari ay 72 oras.

Hakbang 8: Gawin ang Huling Synchronization at Log Check

Pagkatapos ng pagbabago ng DNS, dapat suriin kung may bagong data na naisulat sa lumang server. Ikumpara lalo na ang mga orders, contact form entries, user registrations, at comments. Ang web server access log at error log files ay makakatulong upang maunawaan kung aling mga IP ang nagpapadala ng request sa kung aling server.

Sa unang 24 oras pagkatapos ng migration, subaybayan ang 500 errors, pagtaas ng 404, mabagal na queries, CPU spikes, at email queues. Kung hindi gagawin ang mga pagsusuring ito, ang site ay maaaring magmukhang gumagana ngunit may pagkawala ng conversion na nagaganap sa background.

Propesyonal na Checklist para sa Paglipat ng Site nang Walang Data Loss

Ang sumusunod na checklist ay sumasaklaw sa mga puntong pinakamadalas magdulot ng problema sa praktika. Ang pagmamarka sa listahang ito bago at pagkatapos ng migration ay seryosong nagpapababa sa panganib ng migration.

• Ang oras ng paglipat ay nakaplano sa mga oras na mababa ang trapiko.
• Nakuha ang kumpletong backup ng files, database, email, at DNS.
• Nasubukan na ang backup ay maaaring buksan at i-restore.
• Ang DNS TTL value ay ibinaba nang hindi bababa sa 24 oras bago ang paglipat.
• Naihanda na sa bagong server ang PHP, database, at mga kinakailangang modules.
• Nailipat nang kumpleto ang mga file at nasuri ang mga pahintulot.
• Na-verify ang pagkakatugma ng database character set at collation.
• Na-update ang mga config file ayon sa impormasyon ng bagong server.
• Nagsagawa ng test gamit ang hosts file bago i-live.
• Naka-install ang SSL, nasuri ang mga HTTPS redirect.
• Tamang na-update ang DNS A, AAAA, MX, TXT records.
• Ang lumang server ay pinanatiling aktibo nang hindi bababa sa 48 oras.
• Binabantayan ang Google Search Console, Analytics, at log records.

Mga Post-Migration Checks para Hindi Mawalan ng SEO

Sa teorya, ang server migration ay hindi dapat magdulot ng SEO loss hangga't hindi binabago ang URL structure. Ngunit sa praktika, ang kabagalan, 404 errors, maling robots.txt, kulang na SSL, o mga pagkakamali sa redirect ay maaaring makaapekto sa mga ranking. Dahil dito, ang SEO check pagkatapos ng migration ay kasinghalaga ng teknikal na migration mismo.

Pagsusuri ng URL at Redirect

Kung hindi mo binabago ang URL structure habang naglilipat, ang pangangailangan para sa 301 redirect ay minimal. Ngunit kung sabay na binago ang domain name, permalink structure, o folder structure, ang mga lumang URL ay dapat i-redirect sa kanilang mga bagong katapat gamit ang 301. Ang 302 temporary redirect ay hindi angkop para sa permanenteng paglipat ng SEO signals. Halimbawa, kung ang lumang /produkto/abc na pahina ay inilipat sa bagong /tindahan/abc, dapat gawin ang isa-sa-isang redirect; ang pag-redirect ng lahat ng lumang URL sa homepage ay negatibong nakakaapekto sa karanasan ng gumagamit at pagganap ng SEO.

Pagsusuri ng Robots.txt at Sitemap

Kung ginamit ang Disallow sa robots.txt upang harangan ang mga search engine sa panahon ng pagsubok, dapat itong alisin kapag nag-live na. Ang pagkakamaling ito ay isa sa mga pinaka-klasikong dahilan ng pagkawala ng index pagkatapos ng migration. Ang sitemap file ay dapat maglaman ng mga bagong HTTPS URL, at dapat itong muling ipadala sa pamamagitan ng Google Search Console.

Pagganap at Core Web Vitals

Kahit na mas malakas ang bagong server, ang maling cache setting ay maaaring magpababa ng pagganap. Ang LiteSpeed Cache, Redis, OPcache, CDN, at pag-optimize ng imahe ay dapat na maayos na i-configure. Sa unang linggo pagkatapos ng migration, subaybayan ang PageSpeed Insights, Chrome UX Report, at server logs upang suriin kung may pagkasira sa mga sukatan ng LCP, INP, at CLS. Upang mapabuti ang pagganap ng hosting, maaari mong gamitin ang mga nilalaman ng WordPress speed optimization.

Mga Dapat Pag-ingatan sa Paglipat ng Email

Sa maraming paglipat ng site, ang mga web file ay naisasalin nang walang problema habang ang panig ng email ay nakakaligtaan. Kung ang mga email ay naka-host sa kasalukuyang server, dapat ilipat ang mga mailbox, password ng gumagamit, forwarders, at filters. Ang IMAP synchronization ay isang maaasahang paraan upang ilipat ang mga lumang mail sa bagong mailbox.

Sa panig ng DNS, tinutukoy ng MX record ang mail server, ng SPF ang awtorisasyon sa pagpapadala, ng DKIM ang pagpirma, at ng DMARC ang patakaran sa domain name. Kung mali ang pagkaka-configure sa mga record na ito, ang mga email ay maaaring mapunta sa spam folder o tuluyang ma-reject. Pagkatapos ng migration, dapat magsagawa ng test na pagpapadala sa Gmail, Outlook, at mga corporate mail account; at suriin ang impormasyon ng mail header.

Mga Madalas na Pagkakamali sa Server Migration

Ang pagkakatulad sa mga matagumpay na proyekto ng migration ay ang pag-iwas sa mga simpleng pagkakamali nang maaga. Ang mga sumusunod na pagkakamali ay ang pinakamadalas na nakakaharap na mga problema:

• Pagsasagawa ng migration nang hindi kumukuha ng backup o hindi sinusubok ang backup.
• Pagpapalit ng IP nang hindi ibinababa ang DNS TTL value.
• Pagsasara ng lumang server bago matapos ang DNS propagation.
• Maling paglilipat ng database character set at pagkasira ng mga espesyal na karakter.
• Pagkalimot sa .htaccess o nginx redirect rules.
• Pag-redirect ng HTTPS traffic sa bagong server nang hindi nag-i-install ng SSL.
• Maling pag-update ng email MX at TXT records.
• Pag-iiwan sa cache plugin na nakaturo sa path ng lumang server.
• Hindi pagsubaybay sa Search Console at logs pagkatapos ng migration.

Lalo na para sa mga site na may live na pagbebenta, ang proseso ng migration ay hindi dapat gawin sa kasagsagan ng trabaho tuwing weekdays, kundi sa oras na pinakamababa ang trapiko at dami ng order. Sa malalaking proyekto ng e-commerce, ang pagpaplano ng 15-30 minutong maintenance window ay pumipigil sa mga posibleng hindi pagkakatugma ng data sa background.

Kailan Ka Dapat Kumuha ng Propesyonal na Suporta sa Migration?

Maaaring posible na manu-manong ilipat ang isang simpleng site ng pagpapakilala; ngunit sa ilang mga sitwasyon, ang pagkuha ng propesyonal na suporta ay mas mababa ang gastos at mas ligtas. Ang mga e-commerce site na kumikita ng mataas na buwanang benta, mga kumpanyang may maraming email account, mga portal na gumagamit ng custom software, mga high-traffic media site, at mga negosyong nagho-host ng data na napapailalim sa regulasyon ay kabilang sa grupong ito.

Sa propesyonal na suporta sa paglipat, ang proseso ay karaniwang binubuo ng paunang pagsusuri, backup, pag-setup ng test environment, paglilipat, DNS transition, pagpapatunay, at pagsubaybay. Sa ganitong paraan, hindi lamang ang mga file ang inililipat, kundi pati na rin ang pagpapatuloy ng negosyo. Kung pinaplano mong lumipat sa imprastraktura ng Hostragons, maaari mong suriin ang pahina ng Hostragons hosting solutions upang sama-samang suriin ang mga opsyon sa hosting, domain, at SSL na angkop sa iyong mga pangangailangan.

Konklusyon: Pinipigilan ng Planadong Server Migration ang Downtime at Data Loss

Ang server migration ay hindi isang prosesong dapat katakutan kapag ito ay pinaplano nang tama. Ang susi sa tagumpay ay ang hindi paglaktaw sa mga hakbang ng kumpletong backup, tamang paghahanda ng server, plano sa DNS TTL, test environment, SSL installation, pagsusuri sa email, at pagsubaybay pagkatapos ng migration. Lalo na sa mga site na patuloy na nagbabago ang database, ang huling synchronization at maintenance mode ay gumaganap ng kritikal na papel.

Sa madaling salita, upang ilipat ang site nang walang data loss, huwag magmadali, patunayan ang bawat hakbang, at huwag agad isara ang lumang server. Kung nais mong i-renew ang iyong imprastraktura, mag-alok ng mas mabilis at mas ligtas na karanasan sa web, maaari mong suriin ang mga solusyon sa hosting, domain, at SSL sa Hostragons; at mahinahon at kontroladong likhain ang transition plan na akma sa iyong mga pangangailangan.

Mga Madalas Itanong

Gaano katagal ang server migration?

Ang tagal ay nag-iiba depende sa laki at pagiging kumplikado ng site. Ang isang maliit na WordPress site ay maaaring mailipat sa loob ng 30-60 minuto, samantalang para sa malalaking e-commerce o corporate na proyekto na maraming email, ang proseso kasama ang paghahanda, pagsubok, at DNS propagation ay maaaring tumagal ng 1-3 araw.

Mag-o-offline ba ang aking site sa panahon ng server migration?

Kung gagawin ang tamang pagpaplano, ang downtime ay maaaring mabawasan sa ilang minuto o maaaring hindi ito maramdaman ng mga gumagamit. Para dito, dapat ibaba ang DNS TTL nang maaga, subukan ang bagong server bago i-live, at panatilihing bukas ang lumang server hanggang sa matapos ang DNS propagation.

Ano ang pinakamahalagang hakbang para maiwasan ang data loss?

Ang pinakamahalagang hakbang ay ang beripikadong kumpletong backup. Dapat i-backup ang mga file, database, email, at DNS records; lalo na para sa mga site na bumubuo ng data ng order o membership, ang huling database backup ay dapat gawin pagkatapos i-activate ang maintenance mode.

Nakakaapekto ba ang server migration sa SEO rankings?

Kung ang URL structure ay napanatili, ang site ay mabilis na tumatakbo, at ang SSL at redirects ay ginawa nang tama, ang server migration lamang ay hindi magdudulot ng SEO loss. Ngunit ang 404 errors, maling robots.txt, mabagal na server, o maling 301 redirects ay maaaring negatibong makaapekto sa mga ranking.

Kasama ba ang mga email account sa paglipat ng server?

Kung ang mga email ay naka-host sa lumang hosting, dapat itong ilipat nang hiwalay. Dapat suriin ang mga mailbox, forwarders, filters, at MX, SPF, DKIM, DMARC records. Kung mananatili ang email sa ibang provider, hindi dapat baguhin ang MX records.