Η μεταφορά ενός WordPress site ακούγεται σαν αντιγραφή αρχείων. Δεν είναι. Ένα ζωντανό site είναι τέσσερα ξεχωριστά πράγματα που τυχαίνει να ζουν στο ίδιο μηχάνημα: τα αρχεία, η βάση δεδομένων, τα email, και οι ρυθμίσεις DNS που δείχνουν πού βρίσκονται όλα αυτά. Μεταφέρονται με διαφορετικό τρόπο το καθένα, και τα τρία από τα τέσσερα μπορούν να χαθούν οριστικά αν γίνουν με λάθος σειρά.
Αυτός ο οδηγός περιγράφει τι πραγματικά συμβαίνει. Δεν γράφτηκε για να σε αποτρέψει από μια μεταφορά — γράφτηκε για να ξέρεις τι αναλαμβάνεις, είτε το κάνεις μόνος σου, είτε το αναθέτεις σε εμάς, είτε σε κάποιον άλλο.
Πότε είναι όντως εύκολο
Ας το πούμε πρώτα αυτό, γιατί ισχύει σε ένα μέρος των περιπτώσεων.
Αν το site είναι μικρό (κάτω από 1 GB), τρέχει σε cPanel και πάει σε cPanel, δεν έχει email στον ίδιο server, δεν έχει eshop με ενεργές παραγγελίες, και δεν σε νοιάζει μια ώρα downtime, τότε η μεταφορά είναι μια απόγευματινή δουλειά και συνήθως πετυχαίνει με την πρώτη. Πολλοί πάροχοι το κάνουν και δωρεάν όταν έρχεσαι σε αυτούς.
Όλα όσα ακολουθούν αφορούν τις υπόλοιπες περιπτώσεις.
Τα τέσσερα κομμάτια
Αρχεία. Ο φάκελος του WordPress: πυρήνας, θέμα, πρόσθετα, και ο wp-content/uploads με όλες τις εικόνες. Σε ένα site με λίγα χρόνια ζωής, τα uploads είναι το 90% του όγκου.
Βάση δεδομένων. MySQL ή MariaDB. Εκεί ζουν τα άρθρα, οι σελίδες, τα προϊόντα, οι παραγγελίες, οι χρήστες, τα σχόλια και όλες οι ρυθμίσεις. Χωρίς αυτήν, τα αρχεία είναι ένα άδειο κέλυφος.
Email. Αν οι λογαριασμοί @τοdomainσου.gr φιλοξενούνται στον ίδιο server με το site, είναι εντελώς ξεχωριστό σύστημα με δικά του δεδομένα. Τα μηνύματα δεν μεταφέρονται μαζί με το site. Αυτό είναι το σημείο όπου χάνονται τα περισσότερα δεδομένα σε αποτυχημένες μεταφορές, και ο λόγος είναι απλός: κανείς δεν το σκέφτεται μέχρι να είναι αργά. Ο σωστός τρόπος περιγράφεται στον συγχρονισμό email με imapsync.
DNS. Οι εγγραφές που λένε στον κόσμο πού βρίσκεται το site και πού πάει η αλληλογραφία. Δες τι κάνει κάθε τύπος εγγραφής και πώς συνδέεται ένα domain με hosting.
Μέθοδος 1: Χειροκίνητα
Ο τρόπος με τα περισσότερα βήματα και τον μεγαλύτερο έλεγχο. Δουλεύει παντού, ακόμη και όταν τα δύο panel είναι διαφορετικά ή δεν υπάρχει panel καθόλου.
Αρχεία
Κατεβάζεις όλο τον φάκελο του site μέσω FTP/SFTP ή File Manager και τον ανεβάζεις στον νέο server. Σε site με δεκάδες χιλιάδες εικόνες, το FTP είναι οδυνηρά αργό γιατί ανοίγει νέα σύνδεση για κάθε αρχείο. Πολύ ταχύτερο: φτιάχνεις ένα .zip ή .tar.gz στον παλιό server, το μεταφέρεις ως ένα αρχείο, και το αποσυμπιέζεις στον νέο.
Πρόσεξε τα κρυφά αρχεία. Το .htaccess αρχίζει με τελεία και πολλοί FTP clients δεν το δείχνουν αν δεν τους το ζητήσεις. Χωρίς αυτό, οι permalinks σπάνε και κάθε σελίδα εκτός της αρχικής βγάζει 404.
Βάση
Από το phpMyAdmin του παλιού server κάνεις export σε .sql, και import στη νέα βάση που έχεις δημιουργήσει πρώτα. Δύο συνηθισμένα εμπόδια: το phpMyAdmin έχει όριο μεγέθους στο upload (συχνά 50 MB) και οι μεγάλες βάσεις WooCommerce το ξεπερνούν εύκολα· και το export πρέπει να είναι στο ίδιο charset, αλλιώς τα ελληνικά γίνονται αβγ.
Μετά το import, το wp-config.php πρέπει να δείχνει στη νέα βάση: νέο όνομα, νέος χρήστης, νέος κωδικός, και συχνά διαφορετικό DB_HOST — άλλοι πάροχοι θέλουν localhost, άλλοι συγκεκριμένη διεύθυνση.
Το σημείο που παρακάμπτεται και δεν πρέπει
Αν το site αλλάζει και domain, ή αν πήγαινε σε http:// και πάει σε https://, οι παλιές διευθύνσεις είναι γραμμένες μέσα στη βάση σε χιλιάδες σημεία. Ένα απλό «αντικατάσταση όλων» στο SQL αρχείο καταστρέφει το site: η WordPress αποθηκεύει ρυθμίσεις σε serialized μορφή, όπου κάθε κείμενο συνοδεύεται από το μήκος του. Αν αλλάξεις το κείμενο χωρίς να διορθώσεις το μήκος, οι ρυθμίσεις γίνονται άχρηστες και συνήθως χάνεις widgets, ρυθμίσεις θέματος και page builder περιεχόμενο.
Χρειάζεται εργαλείο που καταλαβαίνει serialization: το Better Search Replace ως πρόσθετο, ή το wp search-replace από terminal.
Πριν κλείσει ο παλιός server, οι λογαριασμοί δημιουργούνται από την αρχή στον νέο και τα μηνύματα αντιγράφονται με imapsync ή με τοπικό συγχρονισμό μέσω IMAP. Χρειάζεσαι τους κωδικούς όλων των λογαριασμών, όχι μόνο του δικού σου. Αν ο παλιός λογαριασμός σβηστεί πρώτος, τα μηνύματα δεν επιστρέφουν.
Μέθοδος 2: Με πρόσθετο backup
Ο συνηθέστερος τρόπος για μη τεχνικούς χρήστες. Ένα πρόσθετο πακετάρει αρχεία και βάση μαζί, και ένα δεύτερο τα ξεπακετάρει στον νέο server.
Δημοφιλείς επιλογές: Duplicator, All-in-One WP Migration, UpdraftPlus, Migrate Guru.
Λειτουργεί καλά μέχρι ένα μέγεθος. Τα προβλήματα εμφανίζονται όταν:
Το site είναι μεγάλο. Οι δωρεάν εκδόσεις έχουν όρια — το All-in-One WP Migration σταματάει γύρω στα 512 MB χωρίς πληρωμένη επέκταση. Πάνω από 2–3 GB, τα πρόσθετα σπάνε στη μέση με timeout ανεξάρτητα από την έκδοση.
Ο παλιός server είναι ήδη προβληματικός. Το πρόσθετο πρέπει να τρέξει εκεί για να φτιάξει το πακέτο. Αν ο λόγος που φεύγεις είναι ότι ο server είναι αργός ή πέφτει, το πακετάρισμα θα αποτύχει ακριβώς για τον ίδιο λόγο.
Το eshop είναι ενεργό. Το πακέτο είναι φωτογραφία μιας στιγμής. Κάθε παραγγελία που μπαίνει μετά το πακετάρισμα και πριν την αλλαγή DNS χάνεται. Σε eshop με κίνηση, η μεταφορά θέλει παράθυρο συντήρησης ή δεύτερο πέρασμα μόνο για τη βάση.
Υπάρχουν premium πρόσθετα με licence δεμένο σε domain. Μετά τη μεταφορά συχνά θέλουν επανενεργοποίηση, και αν η licence έληξε ή αγοράστηκε από τον προηγούμενο κατασκευαστή, δεν έχεις πρόσβαση.
Μέθοδος 3: Από terminal
Ο ταχύτερος και αξιόπιστότερος τρόπος, όταν υπάρχει πρόσβαση SSH και στα δύο μηχανήματα. Απαιτεί άνεση με γραμμή εντολών.
Η λογική είναι τρία βήματα. Πρώτα εξάγεις τη βάση με mysqldump και τη συμπιέζεις. Μετά μεταφέρεις αρχεία και dump με rsync απευθείας από server σε server, χωρίς να περάσουν από τον υπολογιστή σου — σε μεγάλα site αυτό μόνο γλιτώνει ώρες. Τέλος εισάγεις τη βάση στον νέο server και τρέχεις wp search-replace για τις διευθύνσεις.
Το rsync έχει ένα πλεονέκτημα που καμία άλλη μέθοδος δεν προσφέρει: επαναλαμβάνεται. Το τρέχεις μια φορά όσο το site είναι ζωντανό, και ξανά λίγο πριν την αλλαγή DNS. Το δεύτερο πέρασμα αντιγράφει μόνο ό,τι άλλαξε στο μεσοδιάστημα και τελειώνει σε δευτερόλεπτα. Έτσι πετυχαίνεις μεταφορά σχεδόν χωρίς downtime.
Το εμπόδιο είναι η πρόσβαση. Πολλά shared πλάνα δεν δίνουν SSH καθόλου, ή το δίνουν χωρίς rsync και wp-cli εγκατεστημένα. Αν λείπει το SSH στον έναν από τους δύο servers, η μέθοδος δεν εφαρμόζεται.
Τι πάει στραβά
Ασυμβατότητα PHP
Ο νέος server σχεδόν ποτέ δεν τρέχει την ίδια έκδοση PHP. Ένα site που δούλευε σε PHP 7.4 και προσγειώνεται σε PHP 8.3 μπορεί να εμφανίσει λευκή σελίδα, γιατί λειτουργίες που ήταν απλώς αποδοκιμασμένες αφαιρέθηκαν οριστικά.
Το πρόβλημα σπάνια είναι ο πυρήνας του WordPress. Είναι τα παλιά πρόσθετα και θέματα που δεν συντηρούνται πια. Αν το θέμα αγοράστηκε πριν έξι χρόνια και ο δημιουργός εξαφανίστηκε, δεν υπάρχει ενημέρωση — μένει η επιλογή να κλειδώσεις τον νέο server σε παλιά PHP, που σημαίνει έκδοση χωρίς ενημερώσεις ασφαλείας.
Λείπουν επίσης συχνά επεκτάσεις PHP: imagick για επεξεργασία εικόνων, soap για συνδέσεις με ERP, intl, zip. Σε shared hosting μπορεί να μην μπορούν καν να προστεθούν.
Διαφορετικό control panel
cPanel σε cPanel είναι η εύκολη περίπτωση: υπάρχει έτοιμη μεταφορά λογαριασμού που παίρνει αρχεία, βάσεις, email και cron μαζί.
cPanel σε Plesk, ή προς οτιδήποτε άλλο, σημαίνει ότι όλα γίνονται χειροκίνητα. Δεν αλλάζει μόνο η διεπαφή: αλλάζουν οι διαδρομές αρχείων, ο τρόπος που ορίζονται τα cron jobs, το πού ζουν τα αρχεία καταγραφής, και το πώς εκδίδονται τα πιστοποιητικά.
Προς VPS χωρίς panel είναι άλλη κατηγορία δουλειάς. Δεν μεταφέρεις site — στήνεις server. Web server, PHP-FPM, MySQL, τείχος προστασίας, mail stack, backups, παρακολούθηση, ενημερώσεις ασφαλείας. Το site είναι το τελευταίο και μικρότερο κομμάτι. Και από κει και πέρα η συντήρηση είναι δική σου ευθύνη για πάντα.
SSL
Το πιστοποιητικό δεν μεταφέρεται. Εκδίδεται καινούργιο στον νέο server, και για να εκδοθεί πρέπει το domain να δείχνει ήδη εκεί. Υπάρχει δηλαδή ένα παράθυρο όπου το DNS έχει αλλάξει αλλά το πιστοποιητικό δεν έχει βγει ακόμα, και οι επισκέπτες βλέπουν κόκκινη προειδοποίηση ασφαλείας.
Το παράθυρο κρατάει από λίγα λεπτά μέχρι μερικές ώρες, ανάλογα με τον πάροχο. Δες πώς λειτουργεί το SSL.
Αν το site είναι πίσω από Cloudflare, υπάρχει και δεύτερη παγίδα: με λάθος ρύθμιση SSL mode το site μπαίνει σε ατέρμονη ανακατεύθυνση και δεν φορτώνει καθόλου.
Downtime και DNS
Η αλλαγή DNS δεν είναι ακαριαία. Κάθε εγγραφή έχει TTL — χρόνο που οι providers ανά τον κόσμο κρατούν την παλιά τιμή στη μνήμη τους. Με TTL 24 ωρών, ένα μέρος των επισκεπτών σου βλέπει τον παλιό server για μία ολόκληρη μέρα μετά την αλλαγή.
Πρακτικά αυτό σημαίνει ότι για ένα διάστημα δύο servers σερβίρουν το ίδιο site. Σε ενημερωτικό site δεν πειράζει. Σε eshop σημαίνει ότι παραγγελίες πέφτουν σε δύο διαφορετικές βάσεις και κάποιες θα χαθούν.
Ο σωστός χειρισμός: κατεβάζεις το TTL σε 300 δευτερόλεπτα μία μέρα πριν, κάνεις τη μεταφορά, και το ανεβάζεις πάλι μετά. Αν το ξεχάσεις, το παράθυρο δεν συμπιέζεται εκ των υστέρων.
Email που χάνεται
Το χειρότερο σενάριο, και δυστυχώς το πιο συνηθισμένο. Αν αλλάξουν οι εγγραφές MX πριν αντιγραφούν τα μηνύματα, η νέα αλληλογραφία πάει σε άδεια γραμματοκιβώτια ενώ η παλιά μένει σε server που σε λίγες μέρες διαγράφεται.
Χάνονται επίσης οι ρυθμίσεις SPF, DKIM και DMARC. Αν δεν ξαναστηθούν στον νέο server, τα email σου αρχίζουν να καταλήγουν στα ανεπιθύμητα — και το χειρότερο είναι ότι δεν το μαθαίνεις αμέσως. Το μαθαίνεις όταν κάποιος πελάτης πει «δεν έλαβα ποτέ την προσφορά σου».
Δικαιώματα αρχείων και ιδιοκτησία
Μετά από μεταφορά μέσω zip ή rsync, τα αρχεία συχνά ανήκουν σε λάθος χρήστη. Το αποτέλεσμα είναι site που φορτώνει αλλά δεν σε αφήνει να ανεβάσεις εικόνα, να ενημερώσεις πρόσθετο ή να αποθηκεύσεις ρυθμίσεις. Άλλες φορές το ίδιο λάθος δίνει υπερβολικά ανοιχτά δικαιώματα, που είναι κενό ασφαλείας.
Κανόνες server που δεν μεταφέρονται
Το .htaccess δουλεύει σε Apache και LiteSpeed. Στον nginx αγνοείται εντελώς. Ανακατευθύνσεις, κανόνες caching, μπλοκαρίσματα IP, προστασία του wp-login.php — όλα σιωπηλά παύουν να ισχύουν και πρέπει να ξαναγραφούν σε άλλη σύνταξη. Κανένα μήνυμα λάθους δεν σε ειδοποιεί.
Γιατί ο νέος server συμπεριφέρεται αλλιώς
Δύο πλάνα με ίδια τιμή και ίδια χαρακτηριστικά στο χαρτί μπορούν να δίνουν πολύ διαφορετικό site.
Web server
Apache είναι ο πιο συμβατός. Δέχεται .htaccess και δουλεύει με τα πάντα, αλλά καταναλώνει περισσότερη μνήμη ανά ταυτόχρονο επισκέπτη.
LiteSpeed δέχεται κι αυτός .htaccess, οπότε η μεταφορά από Apache είναι ομαλή. Το δυνατό του σημείο είναι το LSCache, ένα σύστημα caching ενσωματωμένο στον ίδιο τον server — αισθητά ταχύτερο από οποιοδήποτε πρόσθετο caching, γιατί απαντά πριν καν ξεκινήσει η PHP. Αν το site σου τρέχει σε LiteSpeed και μεταφερθεί σε Apache, θα σου φανεί πιο αργό ακόμη κι αν το υπόλοιπο μηχάνημα είναι καλύτερο.
nginx είναι ο αποδοτικότερος σε πολλούς ταυτόχρονους επισκέπτες, αλλά αγνοεί το .htaccess. Κάθε κανόνας ξαναγράφεται στη διαμόρφωση του server, πράγμα που σε shared hosting συχνά δεν σου επιτρέπεται καθόλου.
Δίσκος
NVMe έναντι παλαιότερου SSD ή μηχανικού δίσκου: η διαφορά φαίνεται κυρίως στη βάση δεδομένων. Ένα WooCommerce με 20.000 προϊόντα κάνει εκατοντάδες ερωτήματα ανά σελίδα, και εκεί η ταχύτητα δίσκου μεταφράζεται άμεσα σε χρόνο φόρτωσης. Σε μικρό ενημερωτικό site η διαφορά είναι σχεδόν αόρατη.
RAM και CPU
Εδώ κρύβεται η μεγαλύτερη διαφορά μεταξύ πλάνων που μοιάζουν ίδια.
Σε shared hosting μοιράζεσαι το μηχάνημα με δεκάδες ή εκατοντάδες άλλους. Η «εγγυημένη» μνήμη είναι όριο, όχι δέσμευση. Υπάρχουν επίσης όρια που κανείς δεν διαφημίζει: entry processes (πόσα αιτήματα εξυπηρετούνται ταυτόχρονα) και I/O (πόσο γρήγορα διαβάζεις από τον δίσκο). Το entry process limit είναι ο συνηθέστερος λόγος που ένα site «πέφτει» μόλις έρθει κίνηση — δεν εξαντλήθηκε η μνήμη, εξαντλήθηκαν οι ταυτόχρονες συνδέσεις.
Σε dedicated RAM ή VPS, οι πόροι είναι δικοί σου. Ένας γείτονας που δέχεται επίθεση δεν σε ρίχνει. Αλλά η συντήρηση είναι δική σου.
Το πρακτικό συμπέρασμα: σύγκρινε συμπεριφορά, όχι αριθμούς. Ένα πλάνο «8 GB RAM» σε shared μπορεί να αποδίδει χειρότερα από ένα «2 GB» dedicated, αν το πρώτο έχει σφιχτά όρια ταυτόχρονων διεργασιών.
Πόσο διαρκεί στην πραγματικότητα
Η ίδια η μεταφορά είναι το μικρό κομμάτι. Ο χρόνος πάει στον έλεγχο μετά.
Μια σοβαρή μεταφορά περιλαμβάνει έλεγχο κάθε τύπου σελίδας, δοκιμαστική παραγγελία αν υπάρχει eshop, δοκιμή κάθε φόρμας επικοινωνίας, επιβεβαίωση ότι τα email φεύγουν και παραλαμβάνονται, έλεγχο των ανακατευθύνσεων, και παρακολούθηση των σφαλμάτων 404 για μία εβδομάδα.
Για ένα απλό site: μισή μέρα δουλειάς και μια εβδομάδα παρακολούθησης. Για eshop με email στον ίδιο server: αρκετές μέρες, με παράθυρο συντήρησης και σχέδιο επιστροφής αν κάτι πάει στραβά.
Πριν ξεκινήσεις οτιδήποτε
Κράτα πλήρες backup, κατεβασμένο στον υπολογιστή σου, όχι μόνο στον server που πας να εγκαταλείψεις. Σιγουρέψου ότι έχεις πρόσβαση στο μητρώο του domain — χωρίς αυτήν δεν αλλάζει τίποτα. Κατέγραψε τους κωδικούς όλων των email πριν χαθεί η πρόσβαση στον παλιό server. Και μην ακυρώσεις τον παλιό λογαριασμό μέχρι να λειτουργεί ο νέος για τουλάχιστον δύο εβδομάδες. Οι πάροχοι διαγράφουν δεδομένα λήξης γρήγορα, και ένα backup που δεν έχεις κατεβάσει δεν είναι backup.
Δες και πώς λειτουργούν τα backups.
Θέλεις να το αναλάβουμε;
Κάνουμε μεταφορές τακτικά, και προς εμάς και από εμάς. Αν φεύγεις, θα σου δώσουμε πλήρες backup αρχείων και βάσης χωρίς ερωτήσεις — τα δεδομένα είναι δικά σου.
info@symbols.gr, απάντηση εντός μίας ώρας τις εργάσιμες.