After moving a website to a new host, one of the most common reasons for broken pages, login failures, and database errors is an outdated configuration file. Even if the files and database were copied correctly, the application may still be pointing to the old database host, old credentials, a different socket path, or an environment setting that no longer matches the new hosting platform. In many cases, a simple config update is enough to bring the site back online.
This guide explains how to update website configuration files after a host migration, with practical steps for common PHP applications, CMS platforms, and managed hosting environments. It is written for users working in a control panel such as Plesk or a similar hosting panel, especially when the website was migrated within an EU hosting environment and the database connection must be re-established after the move.
Why config files must be updated after a host migration
When a website is moved to a new hosting account or platform, the application usually keeps its old connection details until you change them manually. This is especially important for database-driven websites such as WordPress, Joomla, Drupal, Magento, Laravel, and custom PHP applications.
Typical changes after migration include:
- Database host name or IP address
- Database name
- Database username and password
- Database port or socket path
- Application base URL or site URL
- File paths, cache paths, or log paths
- Environment-specific settings such as debug mode, mail transport, or storage location
If these values are not updated, you may see errors such as:
- “Error establishing a database connection”
- “Access denied for user”
- “Unknown database”
- Blank page after migration
- Redirect loops
- 404 errors on pages that previously worked
- Admin login not working after the move
Before you edit any configuration file
Before changing anything, confirm that the database has already been imported successfully and that the new database user has the correct permissions. Updating a config file without checking the database side often leads to confusion, because the error may be caused by missing privileges rather than wrong credentials.
Check these items first
- The site files were copied to the new hosting account
- The database was exported from the old host and imported on the new host
- A new database user exists on the destination platform
- The new user has full access to the imported database
- You know the database host value required by the platform
- You have a backup of the current configuration file before editing it
In managed hosting and Plesk environments, the database host is often localhost, but some setups use a specific internal host name or socket path. Always check the hosting panel or migration notes for the correct value.
Find the right configuration file
The exact file depends on the application. Most websites keep the database connection settings in a single file or in a small set of environment files. If you are unsure where to look, start by checking the application root directory and common configuration folders.
Common configuration files by platform
- WordPress: wp-config.php
- Joomla: configuration.php
- Drupal: sites/default/settings.php
- Magento: app/etc/env.php
- Laravel: .env
- Symfony: .env or config/packages/*.yaml
- Custom PHP apps: config.php, database.php, settings.php, or .env
If your site uses a framework or custom code, search for terms such as db_host, database, mysql, host, username, or password. In many cases, these values are stored in plain text inside a configuration file.
How to update website config files after moving hosts
The process is usually the same regardless of the application: identify the new database credentials, edit the configuration file, save the changes, and test the connection. Below is a safe sequence you can follow.
Step 1: Create a backup of the configuration file
Before editing, download a copy of the original file or create a duplicate on the server. This makes it easy to restore the previous version if something breaks.
- Use the file manager in your control panel
- Or connect with SFTP/SSH and download the file locally
- Keep the backup in a secure location
Step 2: Open the file in a safe editor
Use a plain text editor that does not change formatting. Avoid rich text editors. If your hosting control panel includes a file editor, check that it preserves line endings and special characters correctly.
Step 3: Locate the database settings
Look for entries such as:
- database name
- database user
- database password
- database host
- table prefix
- port or socket values
In many migrations, only the database host and credentials change. The table prefix usually stays the same unless the application was rebuilt or partially restored.
Step 4: Replace old values with the new host details
Update the configuration file with the credentials from the new hosting platform. In a Plesk or managed hosting environment, these values are usually available in the database section of the control panel.
Make sure the following match exactly:
- Database name: the imported database name on the new host
- Database username: the new user created in the panel
- Password: the current password for that user
- Host: typically localhost or the host value provided by the provider
- Port: if your environment requires a custom port
Be careful with special characters in passwords. Some applications require escaping or quoting depending on how the value is stored in the file.
Step 5: Save and upload the file
Save the updated file and upload it back to the correct directory if needed. If you edited it directly on the server, verify that the file permissions remain correct and that the web server user can read it.
Step 6: Clear cache if the application uses it
Many modern applications cache configuration values. After changing the file, clear the app cache, browser cache, or any server-side cache so the new settings are loaded.
- WordPress cache plugins may need to be cleared
- Laravel may require config cache refresh
- Magento often needs cache flush and reindex steps
- Drupal may require cache rebuild
Examples of common configuration changes
Different applications store configuration in different formats. The examples below show what typically changes after a migration.
WordPress wp-config.php
WordPress usually stores the database settings near the top of the file. The most important values are DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST.
- DB_NAME should match the imported database
- DB_USER should match the user created in the new panel
- DB_PASSWORD should be the new password
- DB_HOST is often localhost, but not always
If the site still loads but redirects incorrectly, you may also need to update site URL values in the database, especially if the domain changed during the migration.
Joomla configuration.php
Joomla uses a configuration file that contains the database settings and the live site path. After moving hosts, check the database host, username, password, and database name. If the site is installed in a different folder, verify the absolute path values as well.
Drupal settings.php
Drupal stores database credentials inside the settings file. If the site was copied to a new server and the database was imported, update the connection array carefully. If file system paths changed, confirm that public and private file paths are still correct.
Magento app/etc/env.php
Magento uses a structured configuration file with database credentials, cache settings, and sometimes queue or session settings. After migration, verify the database section first. A mismatch here can prevent the storefront or admin panel from loading.
Laravel .env
Laravel sites frequently use environment variables. The most common database entries are DB_DATABASE, DB_USERNAME, DB_PASSWORD, and DB_HOST. After updating these values, clear the configuration cache so the app reads the new settings.
How to update config files in Plesk
In Plesk, website configuration is often handled through the file manager, databases section, and domain settings. This makes it easier to reconnect a migrated site without using command-line tools.
Useful checks in Plesk
- Open the domain’s file manager and locate the app config file
- Check the Databases section for the imported database
- Confirm the database user and password
- Verify that the user has access to the database
- Review PHP settings if the site needs a different version or memory limit
- Clear application cache if your stack includes caching tools
If the site still fails after updating the file, compare the imported database name in Plesk with the value in the config. A common issue is a small typo or an extra prefix added by the control panel.
Other settings that may need updates after a move
Database connection details are the most common change, but they are not the only ones. Depending on how the site was built, you may need to update a few additional settings.
Site URL and base path
If the domain changed, or if the site was moved from a staging location to a live domain, update the base URL in the config or database. This helps prevent redirect loops and broken asset links.
File system paths
Some apps store absolute paths to upload directories, cache folders, or logs. These paths can change when moving between hosting accounts, especially if the new platform uses a different home directory structure.
Mail settings
If your site sends emails through SMTP, you may need to update the mail host, port, username, password, or encryption type. A migration can break contact forms, order notifications, and password reset emails if old SMTP settings remain in place.
PHP version and extensions
Configuration files may be correct, but the app can still fail if the new hosting environment uses a different PHP version or lacks required extensions such as mysqli, pdo_mysql, mbstring, xml, or gd. Check compatibility if the site shows a blank page or fatal error after the move.
How to troubleshoot common database config errors
If the site is still not working after the config file update, use the error message as a guide. Most database connection problems are easy to narrow down once you know what to check.
Access denied for user
This usually means the username or password is wrong, or the user does not have permission to access the database. Recheck the credentials in the hosting panel and ensure the user is assigned to the database.
Unknown database
This error means the database name in the config file does not exist on the new host. Confirm the imported database name and check for prefixes added by the control panel.
Can’t connect to local MySQL server
This may mean the host value is wrong, the database service is unavailable, or the application is trying to use a socket path that does not match the new environment. Try localhost first if supported by the host, or use the database host provided by support.
Blank page after update
A blank page can indicate a PHP error, bad syntax in the config file, or incompatible settings. Reopen the file and check for missing quotes, extra commas, or line breaks inserted during editing.
Still seeing the old site or old data
This may be a cache issue rather than a config issue. Clear application cache, CDN cache, browser cache, and any server-side cache. Also confirm that the DNS record points to the new host if the domain was recently moved.
Best practices for updating config files safely
Updating configuration files is a small task, but it affects the whole website. Following a few best practices can save time and prevent unnecessary downtime.
- Always keep a backup of the original config
- Change one thing at a time and test after each change
- Do not reuse old database credentials unless the platform specifically allows it
- Use secure file permissions so the config cannot be read publicly
- Keep credentials in the correct file and avoid storing them in multiple places
- Document the new database host, username, and import name for future reference
If the website is live and receiving traffic, perform the update during a low-traffic window where possible. Even a short config mistake can temporarily break checkout, contact forms, or admin access.
FAQ
Do I always need to edit a config file after moving hosts?
Not always, but for most database-driven websites the answer is yes. If the database name, user, password, or host changed, the application must be updated to match the new environment.
Why does the site work on the old host but not on the new one?
The old host used credentials and paths that are no longer valid. After migration, the app still points to the previous database or file structure until the config file is updated.
Is localhost always the correct database host?
No. Many hosting platforms use localhost, but some require a specific host name, internal address, or socket path. Check the hosting panel or migration instructions for the correct value.
What should I do if I don’t know which file to edit?
Start with the application’s main config file, then search the site root for database settings or environment variables. If you are using a popular CMS or framework, check its documentation for the default config location.
Can the problem be caused by database permissions instead of the config file?
Yes. Even with the correct credentials, the database user must have the right permissions. If the user is not assigned to the imported database, the connection may fail.
Should I update the site URL in the database too?
If the domain changed or the site was moved between staging and production, yes, in many cases you should. Some CMS platforms store the site URL in the database rather than in the config file.
What if I edited the file and the site still shows an error?
Check for syntax mistakes, wrong database host, incorrect password, and missing permissions. Also clear caches and confirm that the database import completed successfully.
Conclusion
Updating website configuration files after moving hosts is a critical step in database and application migration. In most cases, the fix is straightforward: match the config file to the new database name, username, password, and host, then clear any cache and test the site. For hosted environments in Europe, this process is especially important because the migration may include different platform defaults, paths, or database settings even when the website files were copied correctly.
If you follow a careful sequence, back up the original file, verify the database import, update the connection details, and test the application, you can restore the site quickly and reduce downtime. For more complex platforms or custom applications, use the same principle: identify every setting that depends on the old host and replace it with the correct value for the new one.