Миграция на хостинг: казус със спрял сайт

Сайтът работи нормално до петък следобед. В понеделник клиентите виждат стара версия, част от формите не изпращат запитвания, а фирменият имейл не получава нови писма. Това е типичен миграция хостинг казус: преместването е започнало като рутинна задача, но е засегнало сайт, поща, DNS настройки и реалната работа на бизнеса.

При малък офис подобен проблем не е просто техническо неудобство. Ако сайтът на счетоводна кантора не приема запитвания, ако онлайн магазинът не обработва поръчки или кабинетът не получава съобщения от пациенти, прекъсването има пряка цена. Затова миграцията не бива да се свежда до копиране на файлове от един сървър на друг.

Миграция на хостинг: казус от реалната работа

Най-често поводът за смяна на хостинг е разбираем: сайтът е бавен, поддръжката на текущия доставчик не помага достатъчно, ресурсът не стига или цената се е променила. Понякога причината е по-сериозна – чести сривове, компрометиран сайт или стар сървър, който вече не поддържа нужната версия на PHP.

Проблемът започва, когато новият хостинг се избере само по цена и миграцията се направи набързо. WordPress сайтът може да изглежда прехвърлен успешно, но да липсват изображения, поръчки, записи от контактни форми или настройки на плъгини. При WooCommerce рискът е по-голям: в периода на прехвърлянето могат да постъпят нови поръчки, които да останат само на стария сървър.

Един реалистичен сценарий е следният. Фирмен сайт с WordPress и няколко служебни пощенски кутии се премества през уикенда. В понеделник началната страница се отваря, но формата за контакт дава грешка. Имейлите се изпращат от част от устройствата, а на други Outlook и телефоните искат нова парола. Причината не е една: сайтът е копиран, но DNS записите за пощата не са пресъздадени правилно, а SMTP настройката на формата сочи към стария сървър.

Това е причината добрата миграция да започва с преценка какво реално трябва да бъде преместено, а не с натискане на бутон за автоматичен трансфер.

Какво се проверява преди преместването

Преди промяна по домейна се прави архив, но архивът сам по себе си не е достатъчен. Той трябва да съдържа файловете на сайта, базата данни и при нужда пощенските кутии. След това се проверява дали архивът може да бъде използван за възстановяване. Неработещ архив се разбира точно когато вече е късно.

Следва опис на услугите около сайта. Има ли WordPress, WooCommerce, отделна система за резервации, контактни форми, външна поща, поддомейни или DNS записи за услуги като Microsoft 365? Домейнът и хостингът често са при различни доставчици. Това не е проблем, но трябва да е ясно кой има достъп и кой запис ще се променя.

Особено внимание изискват фирмените имейли. Ако пощата е на стария хостинг, миграцията включва създаване на всички кутии, копиране на наличните писма и правилни MX, SPF и DKIM записи. Ако пощата е външна услуга, тя не се мести, но DNS записите й трябва да останат непокътнати. Една неправилна промяна може временно да спре получаването на писма, въпреки че самият сайт работи.

Трябва да се провери и SSL сертификатът. След прехвърляне сайтът може да се отваря, но браузърът да показва предупреждение, че връзката не е защитена. Това създава недоверие у посетителите и често прекъсва плащания, вход в административния панел или изпращане на форми.

Защо не се сменят всички настройки наведнъж

Най-сигурният подход е новата среда да се подготви и тества преди домейнът да сочи към нея. Така се вижда дали сайтът зарежда правилно, дали изображенията са налични, дали формите изпращат писма и дали административният панел работи. При магазин се проверяват кошница, поръчка, плащане и автоматичните известия.

Едва след тази проверка се променят DNS записите. Разпространението им не е мигновено. При част от посетителите новият сайт може да се отвори сравнително бързо, а при други старият да се вижда още известно време. Това не означава непременно грешка, но е важно да има план как се избягва разминаване на данни в този период.

Практичен процес с минимално прекъсване

При стандартен WordPress сайт преместването обикновено може да се извърши дистанционно. Необходимо е да има достъп до текущия хостинг, новия хостинг и администрацията на домейна. Ако липсват пароли или домейнът е регистриран на името на бивш служител или външна агенция, първата задача е да се възстанови контролът. Без това всяка миграция остава зависима от чужд достъп.

Работният процес има ясна последователност: подготвя се проверен архив, създава се копие на сайта на новия сървър, настройват се база данни и PHP версия, след което се тества. После се прехвърлят или запазват настройките за имейл, издава се SSL сертификат и се планира промяната на DNS.

След активирането не е достатъчно само началната страница да изглежда добре. Проверяват се основните страници, входът в WordPress, формите, изпращането и получаването на служебна поща, пренасочванията, мобилната версия и скоростта на зареждане. При електронен магазин се прави тестова поръчка. Тази последна проверка открива голяма част от проблемите, които иначе се появяват първо при клиент.

При малък офис има и организационна страна. Ако пощенските профили трябва да бъдат пренастроени на няколко компютъра и телефона, това се прави в уговорен момент, за да не прекъсва работата на екипа. В София, когато има нужда от помощ с устройства на място, преценката дали случаят изисква посещение спестява излишно чакане и проби.

Най-честите грешки след прехвърляне

Първата е сайтът да бъде изтрит от стария хостинг веднага след смяната. Старият акаунт е разумно да остане активен за кратък договорен период, докато се потвърди, че всичко работи и няма данни, които са останали там.

Втората е да се приеме, че WordPress обновяванията са без значение. Новият сървър може да работи с по-нова версия на PHP и стар плъгин да започне да дава грешка. Понякога обновяването решава проблема, но не винаги е безопасно да се прави директно на работещ сайт. Първо се преценява съвместимостта и наличието на резервно копие.

Третата е пренебрегване на пощата. Клиентите често разбират, че нещо не е наред чак когато партньор се обади по телефон с въпроса защо никой не отговаря. Проверка с реално изпращане и получаване на писма е по-надеждна от това да се гледа дали пощенската програма просто се отваря.

Четвъртата е липсата на човек, който поема отговорност за целия процес. Хостинг доставчикът може да отговаря за сървъра, регистраторът – за домейна, а разработчикът – за сайта. Но когато не е ясно кой следи общата картина, клиентът остава да предава технически обяснения между няколко страни.

Кога миграцията е знак за по-голям проблем

Понякога смяната на хостинг решава скоростта и стабилността. Понякога само премества стар проблем на ново място. Ако сайтът е заразен, има остаряла тема, незащитени администраторски акаунти или плъгини без поддръжка, той остава уязвим независимо къде се намира.

Същото важи за бавния сайт. Новият хостинг може да подобри времето за зареждане, но тежки изображения, прекалено много плъгини или лошо настроен кеш ще продължат да влияят. Практичната преценка е какво има смисъл да се поправи преди преместването и какво може да се планира веднага след него.

IT Doctor подхожда към такива случаи като към работна задача, а не като към поредна техническа процедура: първо се уточнява какво не трябва да спира, после се прави план за преместването и накрая се проверява реалният резултат.

Ако обмисляте смяна на хостинг, подгответе достъпите до домейна, настоящия хостинг и пощата още преди да изтече договорът. Тази малка стъпка дава време миграцията да бъде проверена спокойно, вместо сайтът и служебната комуникация да се оправят под напрежение.