Cara Search and Replace Database WordPress: 7 Langkah Aman

Cara search and replace database WordPress sering baru dicari ketika sebuah website selesai dipindahkan, tetapi alamat lama ternyata masih muncul di berbagai bagian situs. Halaman utama sudah menggunakan domain baru, namun sebagian gambar gagal ditampilkan. Tombol pada landing page masih mengarah ke alamat sebelumnya. Bahkan, pengaturan tema tertentu tetap menyimpan URL dari website lama.

Masalah tersebut tidak selalu berarti proses migrasi gagal. WordPress menyimpan banyak informasi di dalam database, termasuk pengaturan situs, konten, metadata, dan konfigurasi tambahan dari plugin. Mengubah alamat website pada menu Settings saja belum tentu memperbarui seluruh referensi yang tersimpan.

Solusinya adalah melakukan search and replace database, yaitu mencari nilai tertentu dalam database lalu menggantinya dengan nilai baru. Namun, operasi ini harus menggunakan alat yang memahami struktur data WordPress. Kesalahan penggantian dapat merusak konfigurasi, terutama ketika data disimpan dalam format PHP serialized.

Quick Answer: Cara Search and Replace Database WordPress

Cara search and replace database WordPress yang aman adalah membuat backup terlebih dahulu, menentukan URL yang akan diganti, lalu menggunakan plugin Better Search Replace atau perintah WP-CLI dengan dry run sebelum mengeksekusi perubahan.

Urutan dasarnya adalah:

1. Buat backup database dan file website.
2. Tentukan URL atau nilai lama serta penggantinya secara persis.
3. Periksa cakupan tabel dan siapkan pengujian.
4. Jalankan pencarian dalam mode dry run.
5. Lakukan penggantian jika hasil pratinjau sudah benar.
6. Verifikasi URL, gambar, pengaturan, dan fungsi website.
7. Lakukan rollback jika ditemukan perubahan yang tidak diinginkan.

Untuk pengguna shared hosting tanpa akses SSH, Better Search Replace menjadi pilihan yang praktis. Pengelola website yang memiliki akses WP-CLI dapat menggunakan perintah wp search-replace.

Kedua metode mendukung penanganan serialized data. Sebaliknya, menjalankan perintah SQL REPLACE() secara massal tanpa memahami struktur data WordPress berisiko merusak informasi yang tersimpan.

Mengapa URL Lama Masih Tersimpan di Database WordPress?

Sebuah website WordPress bukan hanya kumpulan halaman HTML. Informasi situs tersebar di beberapa bagian database, dan tidak semuanya diperbarui ketika alamat utama diganti.

Beberapa contohnya adalah:

• wp_options: Menyimpan berbagai pengaturan website, tema, dan plugin.
• wp_posts: Menyimpan konten posting, halaman, serta sejumlah jenis konten lainnya.
• wp_postmeta: Menyimpan metadata, termasuk pengaturan khusus yang digunakan plugin atau page builder.
• wp_usermeta: Menyimpan metadata pengguna.
• Custom tables: Tabel tambahan yang dibuat plugin tertentu untuk kebutuhan khusus.

Awalan wp_ pada nama tabel hanya contoh. Instalasi WordPress dapat menggunakan prefix database berbeda.

Bayangkan sebuah website dipindahkan dari https://lama.example.com ke https://baru.example.com.

Anda mungkin sudah memperbarui pengaturan WordPress Address dan Site Address, tetapi isi posting masih menyimpan:

https://lama.example.com/wp-content/uploads/gambar.jpg

Akibatnya, browser tetap mencoba mengambil gambar dari lokasi lama.

Kasus lain muncul pada konfigurasi page builder atau widget. Sebagian nilai tersimpan dalam bentuk array atau objek yang diserialisasi. Mengganti teks secara sembarangan dapat merusak struktur penyimpanannya.

Jika kebutuhan Anda adalah memindahkan seluruh website ke domain baru, baca panduan cara mengganti domain di WordPress. Artikel tersebut membahas proses migrasi secara lebih luas, sedangkan panduan ini berfokus pada operasi database search-replace.

Kapan Search and Replace Database Diperlukan?

Tidak semua perubahan website membutuhkan penggantian database secara massal.

Situasi	Perlukah search-replace?
Memindahkan website dari domain lama ke domain baru	Umumnya diperlukan jika referensi URL lama masih tersimpan
Memindahkan website dari staging ke production	Sering diperlukan untuk mengganti URL lingkungan pengembangan
Mengubah HTTP ke HTTPS	Mungkin diperlukan jika konten atau konfigurasi masih menyimpan URL HTTP
Mengubah satu tautan dalam sebuah artikel	Biasanya cukup mengedit artikel tersebut
Mengganti password database	Tidak menggunakan metode search-replace
Mengganti nama database MySQL	Bukan tugas search-replace URL; perlu penyesuaian konfigurasi database
Memperbaiki database connection error	Diagnosis koneksi terlebih dahulu, bukan langsung mengganti data

Penting membedakan perubahan URL dalam database dengan perubahan nama database atau kredensial koneksi.

Jika Anda sedang mempelajari struktur database dari awal, panduan cara membuat database MySQL menjelaskan komponen dasar yang diperlukan sebelum sebuah website dapat menggunakan database tersebut.

Memahami Risiko Serialized Data Sebelum Mengganti URL

Inilah bagian yang paling sering terlewat dalam tutorial search-replace sederhana.

WordPress dan sejumlah plugin menggunakan PHP serialization untuk menyimpan struktur data tertentu sebagai string.

Serialized data dapat menyertakan informasi mengenai jenis dan panjang suatu nilai. Ketika string diubah tanpa memperbarui struktur tersebut, data mungkin tidak lagi dapat dibaca dengan benar.

Misalnya, sebuah pengaturan menyimpan URL lama bersama informasi panjang string. Ketika URL diganti menjadi alamat yang memiliki jumlah karakter berbeda, panjang yang tercatat juga harus disesuaikan.

Penggantian teks biasa menggunakan fungsi SQL REPLACE() tidak otomatis menangani seluruh aturan serialisasi PHP.

Dampaknya dapat berupa:

• Pengaturan widget gagal dibaca.
• Konfigurasi tema kembali ke nilai default.
• Bagian layout page builder tidak muncul.
• Opsi plugin tertentu menjadi tidak valid.
• Data yang seharusnya berbentuk array gagal diproses.

Karena itu, jangan menjalankan query SQL global hanya untuk mengganti semua kemunculan domain lama, terutama pada tabel pengaturan dan metadata.

Gunakan alat yang memahami serialized data, seperti Better Search Replace atau WP-CLI.

Selain itu, jangan mengubah kolom guid secara massal hanya karena sedang mengganti domain. Kolom tersebut digunakan sebagai identifier konten dan memerlukan pertimbangan tersendiri. Dalam contoh WP-CLI pada panduan ini, kolom tersebut sengaja dilewati.

Cara Search and Replace Database WordPress dalam 7 Langkah Aman

1. Backup Database dan File Website

Sebelum melakukan perubahan, buat cadangan yang dapat dipulihkan.

Minimal, siapkan:

• Export database lengkap dalam format SQL.
• Backup file WordPress, termasuk wp-content.
• Salinan konfigurasi penting, seperti wp-config.php.
• Catatan domain lama, domain baru, dan waktu perubahan.

Untuk database, Anda dapat menggunakan phpMyAdmin melalui panel hosting.

Buka database WordPress yang benar, pilih menu Export, kemudian unduh hasil ekspornya. Pastikan file backup tidak kosong dan disimpan di lokasi yang aman.

Panduan cara mengekspor database dari phpMyAdmin dapat digunakan sebagai referensi jika Anda belum pernah membuat export database secara manual.

Ingat bahwa backup database tidak otomatis mencakup seluruh gambar, plugin, dan file tema. Untuk pemulihan website secara lengkap, Anda biasanya membutuhkan backup database sekaligus file.

Pada website yang aktif menerima pesanan, pendaftaran, atau komentar, tentukan waktu perubahan agar data baru tidak hilang akibat proses pemulihan.

2. Identifikasi Nilai Lama dan Nilai Baru

Jangan langsung mencari nama domain tanpa terlebih dahulu memeriksa format URL yang sebenarnya tersimpan.

Contoh:

Nilai lama:

https://lama.example.com

Nilai baru:

https://baru.example.com

Perhatikan perbedaan antara:

• http://lama.example.com
• https://lama.example.com
• https://www.lama.example.com
• https://lama.example.com/

Masing-masing merupakan string berbeda.

Search-replace biasa mencocokkan rangkaian karakter yang ditentukan. Jika database menyimpan alamat dengan www, pencarian tanpa www belum tentu menemukan seluruh data yang dimaksud.

Jangan langsung mengganti seluruh nama domain tanpa protokol apabila perubahan yang sebenarnya hanya berkaitan dengan satu format URL.

Prinsip penting: Gunakan string paling spesifik yang sesuai dengan tujuan perubahan, bukan string paling pendek yang menghasilkan jumlah kecocokan terbesar.

Untuk migrasi domain, catat juga apakah URL lama masih dapat diakses, apakah SSL domain baru sudah berfungsi, dan apakah aturan redirect sudah disiapkan.

3. Periksa Database dan Lingkungan Pengujian

Pastikan Anda melakukan operasi pada instalasi WordPress yang benar.

Website staging dan production dapat memiliki nama database, prefix tabel, serta konfigurasi yang berbeda.

Periksa nama database pada konfigurasi WordPress atau panel hosting. Jika tersedia, gunakan staging untuk mencoba operasi terlebih dahulu.

Anda juga perlu menentukan apakah website menggunakan:

• Instalasi WordPress tunggal.
• WordPress Multisite.
• Plugin yang membuat custom database tables.
• Page builder yang menyimpan konfigurasi tambahan.
• Sistem toko online atau membership yang aktif menerima transaksi.

Pada WordPress Multisite, cakupan tabel dapat melibatkan beberapa website dalam satu jaringan. Jangan menerapkan perintah penggantian massal seolah-olah seluruh tabel hanya milik satu situs.

Jika Anda mengelola website bisnis yang aktif, koordinasikan perubahan dengan administrator hosting atau developer sebelum melanjutkan.

4. Pilih Metode dan Jalankan Dry Run

Terdapat dua metode yang paling praktis.

Metode A: Better Search Replace

Cocok untuk pemilik WordPress yang mempunyai akses administrator tetapi tidak mempunyai akses SSH.

Metode B: WP-CLI

Cocok bagi administrator teknis yang mempunyai akses command line ke instalasi WordPress.

Keduanya harus diawali dengan dry run, yaitu simulasi operasi yang menampilkan jumlah kecocokan atau perubahan tanpa menyimpan penggantian ke database.

Hasil dry run membantu menemukan kemungkinan kesalahan, misalnya terlalu banyak tabel terpengaruh atau nilai lama ternyata tidak ditemukan.

Namun, jumlah kecocokan bukan satu-satunya indikator keamanan.

Jika hasil menunjukkan ribuan perubahan, periksa apakah hal tersebut masuk akal. Website besar bisa memiliki ribuan referensi URL, tetapi angka besar tidak selalu berarti semua penggantian sudah tepat.

5. Jalankan Penggantian Setelah Hasil Diverifikasi

Setelah backup tersedia dan dry run menunjukkan cakupan yang sesuai, jalankan operasi yang sebenarnya.

Jangan sekaligus menggabungkan beberapa perubahan yang tidak berkaitan, seperti mengganti domain, mengubah path direktori, dan mengganti nama brand pada seluruh database.

Lebih aman melakukan satu perubahan terdefinisi, memeriksa hasil, kemudian melanjutkan ke perubahan berikutnya jika diperlukan.

Catat:

• String pencarian.
• String pengganti.
• Tabel yang diperiksa.
• Jumlah nilai yang berubah.
• Waktu pelaksanaan.
• Metode yang digunakan.

Dokumentasi sederhana tersebut akan memudahkan troubleshooting dan rollback.

6. Verifikasi Hasil pada Database dan Website

Setelah search-replace selesai, jangan hanya membuka homepage lalu menganggap pekerjaan sudah berhasil.

Lakukan pemeriksaan pada beberapa jenis halaman:

1. Homepage: Pastikan website dapat dibuka menggunakan URL baru.
2. Artikel lama: Periksa gambar, tautan internal, dan konten yang sebelumnya menggunakan domain lama.
3. Landing page: Uji tombol CTA, formulir, dan tautan navigasi.
4. Tampilan mobile: Pastikan layout dan komponen interaktif berfungsi.
5. Pengaturan tema atau page builder: Periksa widget, header, footer, dan template penting.
6. Database: Cari kembali nilai lama untuk melihat apakah masih ada referensi yang perlu ditinjau.

Periksa juga browser developer tools untuk mendeteksi file yang gagal dimuat, mixed content, atau permintaan ke domain lama.

Apabila website menggunakan caching, bersihkan cache setelah operasi dan ulangi pemeriksaan menggunakan browser privat.

Perlu dipahami bahwa search-replace database tidak otomatis membuat redirect 301, memperbaiki hardcoded URL dalam file tema, atau mengubah konfigurasi layanan eksternal.

Hal-hal tersebut membutuhkan pemeriksaan tersendiri.

7. Siapkan Rollback dan Selesaikan Dokumentasi

Jika setelah penggantian muncul masalah, hentikan perubahan lanjutan.

Jangan langsung menjalankan operasi sebaliknya tanpa memeriksa kondisi database. Mengganti URL baru kembali ke URL lama mungkin tidak mengembalikan seluruh konfigurasi ke keadaan sebelumnya.

Gunakan backup yang dibuat sebelum perubahan apabila rollback memang diperlukan.

Panduan cara restore backup website membahas metode pemulihan yang dapat digunakan berdasarkan akses hosting dan jenis backup yang tersedia.

Perhatikan bahwa restore database akan mengembalikan data ke waktu backup dibuat. Transaksi, komentar, atau perubahan lain setelah waktu tersebut berisiko hilang. Untuk situs aktif, tentukan strategi pemulihan bersama administrator sebelum menimpa database.

Setelah seluruh fungsi penting diperiksa, simpan catatan pekerjaan dan backup di tempat yang aman.

Metode A: Menggunakan Better Search Replace Tanpa SSH

Untuk pengguna shared hosting, Better Search Replace merupakan salah satu alat yang mendukung pencarian dan penggantian database WordPress, termasuk serialized data.

Plugin ini menyediakan pemilihan tabel dan fitur dry run. Beberapa fitur lanjutan tersedia pada versi berbayar, sehingga jangan menganggap seluruh kemampuan backup atau pemeriksaan detail perubahan tersedia di versi gratis.

Cara Menjalankan Better Search Replace

Langkah pertama: Masuk ke dashboard WordPress sebagai administrator.

Langkah kedua: Buka Plugins → Add New, cari Better Search Replace, lalu instal plugin resmi yang tercantum di direktori WordPress.org.

Sebelum instalasi, periksa kompatibilitas versi WordPress dan PHP pada halaman plugin.

Langkah ketiga: Aktifkan plugin dan buka Tools → Better Search Replace.

Langkah keempat: Pada kolom pencarian, masukkan URL lama secara persis.

Contoh: https://lama.example.com

Pada kolom pengganti, masukkan: https://baru.example.com

Langkah kelima: Pilih tabel database yang memang perlu diperiksa.

Jika seluruh tabel WordPress terkait migrasi perlu diproses, pastikan tabel tersebut berasal dari instalasi yang benar. Hindari memilih tabel milik aplikasi lain yang menggunakan database sama.

Langkah keenam: Pastikan opsi Run as dry run atau opsi simulasi yang tersedia tetap aktif, kemudian jalankan pemeriksaan.

Nama dan susunan kontrol dapat berubah mengikuti versi plugin, tetapi tujuan tahap ini adalah mendapatkan laporan tanpa menulis perubahan ke database.

Langkah ketujuh: Tinjau hasilnya. Setelah yakin nilai dan cakupannya benar, nonaktifkan opsi dry run lalu jalankan penggantian sebenarnya.

Langkah kedelapan: Periksa frontend dan lakukan pencarian ulang untuk memastikan nilai lama yang relevan tidak lagi tersimpan.

Jangan mengulangi proses secara membabi buta jika sejumlah kecocokan tetap ditemukan. Beberapa referensi mungkin sengaja disimpan, berkaitan dengan domain eksternal, atau berasal dari format yang berbeda.

Setelah selesai, pertimbangkan menonaktifkan atau menghapus plugin apabila tidak lagi diperlukan. Ini membantu mengurangi komponen administratif yang tidak digunakan.

Metode B: Search and Replace dengan WP-CLI

WP-CLI menyediakan perintah wp search-replace yang mendukung serialized data dan simulasi perubahan.

Metode ini memerlukan akses command line serta instalasi WP-CLI yang berfungsi. Jalankan perintah dari direktori WordPress yang benar atau gunakan parameter path yang sesuai.

Membuat Backup Database

Contoh perintah:

wp db export backup-sebelum-search-replace.sql

Perintah tersebut membuat export database. Simpan file SQL di lokasi aman di luar direktori yang dapat diakses publik, serta pastikan file tidak tertinggal di web root.

Jangan menggunakan nama file contoh sebagai pengganti kebijakan backup yang lebih lengkap, terutama pada situs production.

Menjalankan Dry Run

Gunakan perintah berikut:

wp search-replace 'https://lama.example.com' 'https://baru.example.com' --skip-columns=guid --dry-run

Opsi --dry-run menjalankan pemeriksaan tanpa menyimpan perubahan ke database.

Sementara itu, --skip-columns=guid digunakan untuk melewati kolom GUID dalam operasi penggantian.

Laporan hasil membantu administrator menilai tabel dan jumlah nilai yang berpotensi berubah.

Menjalankan Penggantian

Setelah hasil dry run sesuai:

wp search-replace 'https://lama.example.com' 'https://baru.example.com' --skip-columns=guid

Perintah tersebut melakukan perubahan pada tabel yang secara default dikelola oleh objek database WordPress.

Jika website memiliki tabel plugin tambahan, jangan langsung menggunakan opsi --all-tables tanpa memeriksa kepemilikan dan cakupan tabel. Database tertentu dapat digunakan oleh lebih dari satu aplikasi.

Memeriksa Kembali URL Lama

Setelah proses berjalan:

wp search-replace 'https://lama.example.com' 'https://baru.example.com' --skip-columns=guid --dry-run

Jika tidak ada lagi kecocokan pada tabel yang diperiksa, hal tersebut merupakan indikator bahwa string tersebut telah ditangani dalam cakupan pencarian yang sama.

Namun, ini bukan bukti bahwa semua URL pada file, konfigurasi server, atau layanan eksternal sudah benar.

Untuk struktur serialized data yang kompleks, dokumentasi WP-CLI juga menyediakan opsi --precise. Opsi tersebut memaksa pemrosesan menggunakan PHP dan dapat lebih lambat, sehingga sebaiknya dipakai berdasarkan kebutuhan teknis.

Dokumentasi lengkap tersedia pada WP-CLI Search Replace Command.

Troubleshooting: Ketika Search and Replace Tidak Memberikan Hasil

Gejala	Kemungkinan penyebab	Pemeriksaan pertama
Dry run menunjukkan nol kecocokan	Format URL pencarian berbeda atau tabel belum tercakup	Periksa HTTP/HTTPS, www, dan cakupan tabel
URL lama masih muncul di website	Cache, hardcoded URL, atau data yang belum terproses	Periksa sumber HTML, cache, dan konfigurasi tema
Gambar hilang setelah penggantian	Path gambar salah atau file belum dipindahkan	Periksa URL gambar dan keberadaan file
Layout page builder rusak	Data konfigurasi berubah atau cache layout belum diperbarui	Periksa konfigurasi dan mekanisme regenerasi milik page builder
Plugin kehabisan waktu proses	Ukuran database atau batas sumber daya hosting	Gunakan batch/metode yang didukung atau koordinasi dengan hosting
Website menampilkan database connection error	Kredensial atau server database bermasalah	Periksa wp-config.php, database, dan status server

Untuk gejala terakhir, baca panduan mengatasi Error Establishing a Database Connection sebelum mencoba mengubah lebih banyak data.

Bagaimana Jika URL Lama Masih Ada Setelah Dry Run Ulang?

Mulailah dari pertanyaan: apakah URL lama tersebut memang harus dihapus?

Sebuah database dapat menyimpan histori, log, referensi dokumen lama, atau konfigurasi tertentu yang memang perlu dipertahankan. Tidak semua kecocokan berarti ada kesalahan.

Jika URL masih tampil pada frontend, identifikasi sumbernya terlebih dahulu.

Periksa apakah URL berasal dari isi posting, metadata, pengaturan plugin, halaman cache, atau file tema. Dengan demikian, Anda dapat memperbaiki sumber masalah tanpa mengubah data lain yang sebenarnya tidak berkaitan.

Bagaimana Jika Website Tidak Bisa Diakses Setelah Penggantian?

Hentikan percobaan penggantian berikutnya.

Periksa terlebih dahulu apakah masalah berkaitan dengan konfigurasi WP_HOME dan WP_SITEURL, pengaturan WordPress Address, SSL, DNS, atau database.

Konstanta URL yang didefinisikan dalam wp-config.php dapat mengesampingkan nilai database yang digunakan WordPress. Oleh karena itu, perubahan nilai database saja belum tentu menyelesaikan konflik konfigurasi URL.

Jika konfigurasi tidak dapat dipulihkan dengan aman, gunakan backup sebelum operasi dan lakukan restore secara terkendali.

Kesalahan yang Harus Dihindari

Ada beberapa kebiasaan yang membuat operasi sederhana berubah menjadi masalah besar.

Menjalankan replace tanpa backup. Ketika perubahan merusak konfigurasi, tidak tersedia titik pemulihan yang dapat dipercaya.

Menggunakan pencarian terlalu luas. Mengganti potongan nama domain atau kata umum dapat memengaruhi data yang tidak dimaksudkan.

Mengabaikan serialized data. SQL replacement langsung dapat merusak nilai yang menyimpan informasi struktur dan panjang string.

Mengubah semua tabel tanpa pemeriksaan. Tabel tambahan mungkin mempunyai fungsi khusus atau bahkan digunakan aplikasi lain.

Menganggap operasi sukses hanya karena muncul pesan completed. Keberhasilan teknis harus dibuktikan melalui verifikasi frontend dan database.

Mengabaikan transaksi yang sedang berlangsung. Pada situs aktif, perubahan database dan rollback dapat berinteraksi dengan data baru.

Mengira search-replace otomatis menyelesaikan SEO migrasi. Redirect 301, canonical URL, sitemap, dan konfigurasi domain baru tetap memerlukan pemeriksaan tersendiri.

Praktik yang lebih baik adalah memperlakukan search-replace sebagai operasi pemeliharaan database dengan tahapan persiapan, eksekusi, validasi, dan pemulihan.

FAQ Seputar Search and Replace Database WordPress

Apakah search and replace WordPress bisa dilakukan melalui phpMyAdmin?

Secara teknis, phpMyAdmin dapat menjalankan query SQL untuk mengubah nilai database. Namun, penggantian massal menggunakan fungsi SQL biasa tidak direkomendasikan untuk data WordPress yang mungkin diserialisasi.

Lebih aman menggunakan Better Search Replace atau WP-CLI. phpMyAdmin tetap bermanfaat untuk membuat backup dan memeriksa database.

Apakah Better Search Replace mengubah file website?

Tidak. Operasi search-replace database bekerja pada nilai yang tersimpan di database. File PHP, gambar, konfigurasi server, dan aset lain di filesystem tidak otomatis berubah.

Apakah semua tabel harus dipilih?

Tidak selalu. Cakupan tabel harus mengikuti tujuan perubahan dan struktur instalasi WordPress. Periksa tabel yang berkaitan sebelum menjalankan operasi, khususnya pada Multisite atau instalasi dengan custom tables.

Apakah search-replace bisa memperbaiki mixed content?

Bisa membantu jika masalahnya berasal dari URL HTTP yang tersimpan di database. Namun, mixed content juga dapat berasal dari file tema, skrip eksternal, atau konfigurasi lain. Karena itu, pemeriksaan browser tetap diperlukan.

Apakah perlu mengubah GUID setelah mengganti domain?

Untuk operasi migrasi URL yang umum, jangan mengganti kolom GUID secara massal tanpa alasan teknis yang jelas. Contoh WP-CLI dalam artikel ini menggunakan --skip-columns=guid, sebagaimana juga ditunjukkan dalam dokumentasi migrasi WordPress.

Apakah jumlah perubahan pada dry run harus sama dengan hasil akhir?

Dry run memberikan gambaran nilai yang akan diproses pada kondisi database saat pemeriksaan dilakukan. Jika database berubah sebelum eksekusi sebenarnya, hasil dapat berbeda. Inilah salah satu alasan operasi sebaiknya dilakukan dalam jendela pemeliharaan yang terkendali.

Referensi Teknis

• WordPress Developer Resources — WP-CLI Search Replace
• WordPress.org — Better Search Replace Plugin
• WordPress Developer Resources — Migrating WordPress
• WordPress Developer Resources — Backing Up Your Database
• WordPress Developer Resources — Editing wp-config.php