- We offer certified developers to hire.
- We’ve performed 1500+ Web/App/eCommerce projects.
- Our clientele is 1000+.
- Free quotation on your project.
- We sign NDA for the security of your projects.
- Three months warranty on code developed by us.
Moving a WordPress website from localhost to live hosting is one of the most important steps in the website development process. Local development gives you a safe environment where you can design pages, configure plugins, customize themes, create content, test functionality, and make changes without exposing unfinished work to visitors.
Eventually, however, that locally developed website needs to become accessible on the internet.
That is where WordPress migration from localhost to live hosting comes in.
The process may sound complicated because a WordPress website is not simply a collection of files. A typical installation contains WordPress core files, themes, plugins, uploaded media, configuration settings, and a database containing posts, pages, users, menus, settings, and other information.
To move the website successfully, you need to transfer both the website files and the database, configure the live hosting environment, update URLs, verify permissions, and test the website thoroughly.
This guide explains how to migrate a WordPress website from localhost to a live server using practical methods. It covers manual migration, database export and import, URL replacement, hosting configuration, troubleshooting, security, SEO considerations, and post-migration testing.
Whether you developed your WordPress website using XAMPP, WAMP, MAMP, Local, Laragon, or another local development environment, the underlying migration principles are largely the same.
WordPress localhost to live hosting migration means moving a WordPress website developed on a local computer to a publicly accessible web server.
A localhost website normally exists only on your computer.
For example, you might access it through an address such as:
http://localhost/mywebsite
or:
http://localhost/wordpress
A live website uses a real domain and hosting account, such as:
https://example.com
The migration connects these two environments.
In practical terms, the process involves moving:
You also need to change references from the localhost URL to the live domain.
For example, a local website might use:
http://localhost/mywebsite
After migration, it should use:
https://example.com
This URL change is particularly important because WordPress stores URLs in its database. Simply uploading the files will not automatically convert every localhost reference into the production domain.
A successful migration therefore involves both file migration and database migration.
Before migrating a website, it helps to understand what actually exists inside your local WordPress installation.
A standard WordPress environment has three major components:
Applications such as XAMPP and WAMP commonly provide the local server components required to run WordPress.
For example, a typical XAMPP installation can provide Apache and MariaDB or MySQL functionality.
WordPress then runs on top of that environment.
Your website’s files might be stored somewhere similar to:
C:\xampp\htdocs\mywebsite
The corresponding database might be named:
mywebsite_db
Your local browser accesses the WordPress installation through an address such as:
http://localhost/mywebsite
When you move the site online, the architecture changes.
Instead of:
Your computer → Local web server → Local database → WordPress
you have:
Visitor → Internet → Hosting server → Database server → WordPress
This is why migration requires more than copying a folder.
The live server needs a functioning database, correct database credentials, appropriate PHP configuration, working domain settings, and access to the WordPress files.
Before beginning the migration, prepare everything you need.
At minimum, you should have:
You should also know:
If the website is important, do not begin migration without creating a backup.
A backup gives you a recovery point if something goes wrong.
Before touching the live website, use this checklist.
Your live hosting environment should meet the requirements of your WordPress installation.
Important considerations include:
Do not choose hosting solely because it is inexpensive.
A poorly configured hosting environment can create problems after migration, including:
For a professional project, evaluate the hosting environment according to the website’s expected traffic and technical requirements.
If you are hiring an agency or WordPress development company to handle a migration, choose a provider with demonstrated experience in WordPress deployment rather than relying only on attractive pricing.
A WordPress installation consists of numerous files and folders.
Some of the most important directories include:
This contains files responsible for the WordPress administration area.
This contains core WordPress libraries and functionality.
This is particularly important during migration.
The wp-content directory generally contains:
For many migrations, wp-content is the directory that contains most of your customized website assets.
This configuration file contains important database connection information and other settings.
It must be configured for the live environment.
On Apache servers, this file can contain rewrite rules used by WordPress and other applications.
Not every hosting environment uses .htaccess, but when it exists, it can be important.
WordPress stores a significant amount of website information in its database.
The database can contain:
This explains why copying only the WordPress files does not produce a complete migration.
Imagine copying your website folder but leaving your posts, pages, menus, settings, and users behind.
The result would not be your complete website.
The database must therefore be exported from the localhost environment and imported into the live server.
Always begin with a backup.
A practical WordPress backup has two components:
Locate your local WordPress installation.
For example, with XAMPP it may be stored under:
htdocs
Create a compressed archive of your WordPress directory.
You can use ZIP format on Windows or another archive format supported by your operating system.
Store the archive somewhere outside the WordPress directory.
For additional safety, maintain another copy on a separate storage location.
Open your local database management tool, commonly phpMyAdmin.
Select the WordPress database.
Choose the export function.
For a normal website, a standard SQL export is usually appropriate.
Download the resulting SQL file.
You should now have something similar to:
mywebsite-files.zip
and:
mywebsite-database.sql
These two files provide a recovery point for the migration.
Log in to your hosting control panel.
Depending on the hosting provider, you may use a control panel such as cPanel, Plesk, or a custom dashboard.
You need to determine the correct document root for your domain.
For example, a primary domain might use:
public_html
A subdomain could use a different directory.
Do not upload your WordPress installation to an arbitrary folder.
If your domain is supposed to display the website at:
example.com
the WordPress files need to exist in the document root associated with that domain.
Create a new database for the WordPress installation.
Depending on the hosting environment, you may need to create:
Make sure the database user has the required permissions for the database.
Write these details down temporarily:
Database name:
Database username:
Database password:
Database host:
The database host is commonly localhost on traditional hosting environments, but do not assume that is always the case.
Use the value supplied by your hosting provider.
This information will later be added to wp-config.php.
Open phpMyAdmin or the database administration tool associated with your local environment.
Select the correct WordPress database.
Before exporting, verify that you have selected the database used by the website you intend to migrate.
Choose Export.
For most standard migrations:
The SQL file can contain a substantial amount of information.
Do not edit it manually unless you understand exactly what you are changing.
Now upload your WordPress files to the production server.
You can commonly use:
For a smaller website, the hosting file manager may be convenient.
For larger websites, SFTP or SSH can provide better control.
A practical approach is to upload the compressed WordPress archive and extract it on the server.
For example:
mywebsite.zip
After extraction, confirm that the WordPress files are located directly inside the intended document root.
A common mistake is accidentally creating:
public_html/mywebsite/
when the domain expects:
public_html/
In that situation, the website might appear at an unexpected path or fail to load properly.
Return to the live database management interface.
Select the newly created WordPress database.
Choose Import.
Upload your SQL file.
Start the import.
If the database is large, your hosting provider may impose limits on upload size or execution time.
In that situation, you may need an alternative method such as:
Do not repeatedly upload a large database if the hosting environment is timing out.
Check the hosting limits first.
Now connect the WordPress files to the live database.
Open:
wp-config.php
Locate the database configuration values.
They typically include definitions for:
Replace the localhost database credentials with the credentials created on your live server.
The values must correspond exactly to the live database.
A mismatch can produce an error similar to:
Error establishing a database connection
Do not change unrelated configuration settings unless you know why they need to be changed.
Before editing wp-config.php, keep a backup copy.
This is one of the most important parts of WordPress localhost migration.
Your local website may contain URLs such as:
http://localhost/mywebsite
Your live site may use:
https://example.com
Changing the WordPress Address and Site Address alone may not replace every stored localhost reference.
URLs can exist in:
A basic SQL replacement can therefore be dangerous because WordPress and plugins may store serialized data.
A safe search-and-replace tool that understands serialized data is preferable.
Some WordPress values are stored with information about string length.
If a URL changes from:
http://localhost/site
to:
https://example.com
the character count changes.
A simplistic database replacement can corrupt serialized values.
This is why migration tools and WordPress-aware search-and-replace solutions are often safer than indiscriminate SQL replacements.
WordPress has two important URL settings:
These normally represent the URL where WordPress is installed and the public URL of the website.
After migration, both generally need to point to the production domain.
For example:
Local:
http://localhost/mywebsite
Live:
https://example.com
The exact configuration depends on how the WordPress installation is structured.
If your website is intentionally installed in a subdirectory, do not remove that path without understanding the implications.
After migration, visit the WordPress administration dashboard.
Go to:
Settings → Permalinks
You do not necessarily need to change the permalink structure.
Simply save the existing settings.
This causes WordPress to regenerate rewrite rules.
It is a simple but effective troubleshooting step for 404 errors.
For example, your homepage might work while URLs such as:
example.com/about-us/
return a 404 error.
Refreshing the permalink settings can resolve this when the underlying issue is a missing or outdated rewrite configuration.
Your domain must point to the live hosting environment.
This generally involves DNS configuration.
Depending on the hosting setup, you might update:
If your hosting provider supplies nameservers, you may be instructed to point the domain’s nameservers to them.
If you manage DNS elsewhere, you may instead need to point the appropriate DNS record to the hosting server.
DNS changes can take time to propagate.
During propagation, different users or networks may temporarily receive different DNS results.
Do not panic if the website does not become available everywhere immediately after a DNS change.
A live WordPress website should use HTTPS.
Your production website should normally resolve as:
https://example.com
rather than:
http://example.com
SSL protects data transmitted between visitors and the server and is an essential part of modern website deployment.
Many hosting providers offer automated SSL certificates.
After SSL is enabled:
Never assume the migration worked simply because the homepage loads.
Perform a complete website test.
Check:
Open:
Submit test forms.
Confirm that:
If the site has user accounts, test:
Check images, videos, PDFs, and other uploads.
Use multiple screen sizes.
A website can appear correct on desktop while navigation or forms fail on mobile.
There are two broad ways to migrate WordPress.
You move:
yourself.
A migration plugin packages or transfers much of the process.
Neither method is universally better.
Manual migration gives you greater visibility and control.
Plugins can make routine migrations easier, especially for users who do not want to work directly with databases.
However, plugins can encounter problems with:
Understanding manual migration remains valuable even when using a plugin.
XAMPP is widely used for local WordPress development.
A typical XAMPP migration involves:
The local installation may be stored in:
C:\xampp\htdocs\website
Your database may be managed through the local phpMyAdmin interface.
Remember that the XAMPP configuration itself does not need to be transferred.
You are transferring the WordPress application and its data, not the entire local server stack.
WAMP provides another popular Windows-based local development environment.
The migration process is similar to XAMPP.
The important difference is simply where and how the local environment stores its files and database services.
The migration remains:
Local WordPress files + local database → live server files + live database
Do not attempt to copy the entire WAMP installation to the hosting server.
The live host already provides its own web server, PHP environment, and database system.
MAMP is commonly used for WordPress development on macOS.
The same fundamental process applies.
Back up the WordPress directory.
Export the database.
Create the production database.
Upload the files.
Import the database.
Update configuration.
Replace local URLs.
Configure DNS and SSL.
Test everything.
The local server application itself does not need to be migrated.
Only the website’s application files and data need to be deployed.
Some developers use dedicated WordPress local development applications instead of traditional Apache stacks.
Regardless of the tool, identify these two assets:
Website files
and
Database
Once those are available, the migration principles remain largely identical.
This makes the process portable between local development environments.
WordPress migrations can fail for many reasons.
Some of the most common problems include:
The important thing is to troubleshoot systematically.
Do not make ten changes simultaneously.
Change one variable at a time and test the result.
A database connection error usually means WordPress cannot communicate correctly with the database.
Check:
Make sure the name in wp-config.php exactly matches the live database.
Confirm the database user exists.
Confirm the password is correct.
Use the host specified by your hosting provider.
Make sure the database user has appropriate privileges.
If credentials are correct but the database server is unavailable, contact the hosting provider.
A completely blank WordPress page can result from:
Start by determining whether the problem affects:
If you have server logs, inspect them.
You can also temporarily disable plugins to determine whether one is responsible.
Do not permanently disable security or essential plugins without understanding the consequences.
If the homepage works but individual pages return 404 errors, first refresh the permalink settings.
Go to:
Settings → Permalinks
Then click Save Changes.
If that does not resolve the issue, investigate:
The correct solution depends on the hosting stack.
Broken images after migration are often caused by incorrect URLs.
For example, an image may still reference:
http://localhost/mywebsite/wp-content/uploads/…
instead of:
https://example.com/wp-content/uploads/…
Search for remaining localhost references.
Also verify that the uploads directory was actually transferred.
Check file permissions if files exist but cannot be served.
If you use a CDN or caching system, clear its cache after correcting the URLs.
Migration can introduce redirect loops.
For example:
http → https → http → https
This may happen because HTTPS is enforced in multiple places with conflicting rules.
Possible sources include:
Check each layer systematically.
Avoid stacking multiple redirect mechanisms unless there is a clear reason.
A website can use HTTPS while some resources still load over HTTP.
For example:
https://example.com
may load an image from:
http://example.com/image.jpg
Browsers can flag such resources as mixed content.
Search your website for old HTTP references.
Update internal resources to HTTPS.
Be particularly careful with:
Your localhost environment and live server may use different PHP versions.
This can create unexpected errors.
For example, a plugin or theme might work on your local development environment but fail after deployment because the production server uses a different PHP version.
Before migration, identify:
Do not blindly switch PHP versions on a production website.
Test changes carefully.
Moving from localhost to live hosting can have significant SEO implications.
Fortunately, a normal localhost-to-domain migration does not inherently damage SEO.
The bigger risk comes from launching the site incorrectly.
Common SEO-related problems include:
Before launch, check your SEO configuration carefully.
If the website is completely new and has never been indexed, SEO migration is relatively straightforward.
If you are replacing an existing live website with a locally developed version, the situation is different.
You should preserve:
If URLs change, create appropriate redirects from old URLs to their corresponding new destinations.
Do not redirect every old page to the homepage simply because it is convenient.
A relevant page-to-page redirect generally provides a better user experience.
After your website becomes live, verify the correct property in Google Search Console.
Review:
If the domain itself is changing from one domain to another, additional migration procedures may be required.
A localhost-to-production deployment normally represents the launch of a website rather than a domain migration.
Your local website may feel extremely fast because everything runs on your own computer.
Do not assume the live website will behave the same way.
Production performance depends on:
After migration, measure real performance.
Do not optimize solely based on how the site feels on the development computer.
A localhost website is generally not exposed to the public in the same way as a live website.
Once the website goes online, security becomes a production concern.
Before launch:
Do not install dozens of security plugins simply because they sound useful.
Security should be approached as a layered system.
A migration backup is not enough.
Once the website is live, establish an ongoing backup strategy.
A useful backup plan can include:
A backup that has never been tested should not automatically be considered a reliable recovery strategy.
Test restoring backups periodically.
Follow these principles for a smoother migration.
Keep both files and database backups.
Once the migration begins, maintain a stable copy.
Keep production credentials securely stored.
Avoid unsafe database manipulation.
Whenever possible, test the production environment before making the domain live.
Do not launch a new production website without properly configuring HTTPS.
A visually correct website can still have broken form functionality.
Website email frequently behaves differently between localhost and production.
Migration can expose differences in fonts, caching, or resource loading.
Do not treat deployment as the final step.
Use the following checklist when performing a manual WordPress localhost-to-live migration.
Yes. WordPress websites developed on localhost can be migrated to virtually any compatible hosting environment.
You normally need to move the WordPress files, transfer the database, update configuration, replace local URLs, configure the domain, and test the production website.
Not necessarily.
If you already have a complete WordPress installation locally, you can migrate the existing files and database.
Some hosting providers offer automated WordPress installation, but that does not mean you must start from a fresh installation.
Yes.
A manual migration can be performed using file transfer, database export and import, configuration editing, and URL replacement.
Yes.
Migration plugins can simplify the process, particularly for smaller websites.
However, always maintain independent backups.
The database probably contains references to the local URL.
You need to update those references carefully.
Common causes include old localhost URLs, missing uploads, incorrect permissions, or incorrect HTTPS configuration.
Usually because the database name, username, password, host, or permissions in wp-config.php are incorrect.
Refreshing the WordPress permalink settings is one of the first things to try.
If that fails, inspect rewrite configuration and server settings.
A properly executed localhost-to-production deployment should not inherently harm SEO.
However, broken URLs, incorrect indexing settings, missing redirects, or technical errors can affect search visibility.
A small website can often be migrated relatively quickly.
Larger websites may require considerably more time because of database size, media volume, hosting limitations, DNS changes, testing, and troubleshooting.
No.
You normally migrate the WordPress website files and database rather than the entire XAMPP environment.
Nothing automatically happens to it.
Your local copy remains on your computer unless you delete or modify it.
Keeping the local copy until the live site has been thoroughly tested is recommended.
For simple brochure websites, migration is usually straightforward.
More complex WordPress websites require additional planning.
If your website uses WooCommerce, pay particular attention to:
Do not treat a busy WooCommerce database like a static brochure website database.
If orders can continue arriving on the old production environment during migration, you need a carefully planned deployment process to prevent data loss.
Membership websites contain sensitive user data.
Test:
WordPress Multisite has additional configuration requirements.
A standard single-site migration procedure may not be sufficient.
Check:
Local development keys are often not appropriate for production.
Instead of immediately pointing the domain at a newly migrated website, consider testing the production environment first.
A controlled deployment can involve:
This approach reduces the amount of troubleshooting required after DNS propagation.
Local development and staging are not identical.
Your website runs on your computer.
It is useful for:
Your website runs on a server environment similar to production but is generally not the primary public website.
Staging is useful for:
The production website is the live site visitors use.
For professional workflows, a common structure is:
Local → Staging → Production
This reduces the chance of introducing untested changes directly into the live website.
Avoid these common mistakes.
Keep the original until production has been validated.
Serialized data can be damaged by simplistic replacements.
It becomes difficult to identify the source of an error.
HTTPS should be part of the launch process.
Contact forms are often overlooked.
Local email behavior frequently differs from production.
Old cached content can make you believe a migration failed even after the underlying website has been fixed.
Server and PHP logs can provide valuable clues.
The terms migration and deployment are sometimes used interchangeably, but there is a useful distinction.
Migration focuses on moving an existing website from one environment to another.
Deployment focuses on publishing a website or application into a target environment.
A localhost-to-live WordPress project can involve both.
You are migrating the website’s files and database while simultaneously deploying it to the production hosting environment.
Understanding this distinction becomes particularly useful when working with professional development workflows.
Suppose you developed a WordPress website locally.
Your local URL is:
http://localhost/companysite
The WordPress files are stored under your local server’s document directory.
The database is called:
companysite_db
You purchase hosting and connect:
companyexample.com
Your production process would look approximately like this:
WordPress files:
localhost/companysite
Database:
companysite_db
Files:
public_html/
Database:
companyexample_wp
Domain:
https://companyexample.com
You would:
This example illustrates the overall logic without depending on a particular hosting provider.
Large websites require additional planning.
Problems may occur because of:
For large migrations, consider:
Do not assume that a method that works for a 50 MB website will work equally well for a multi-gigabyte website.
For a new website, downtime may not be relevant because there is no existing production site.
For an established website being replaced by a locally developed version, minimizing downtime becomes important.
A typical strategy is:
The exact process depends on how frequently the existing production website changes.
For websites receiving frequent orders, comments, registrations, or other dynamic activity, database synchronization requires additional planning.
Email is one of the most commonly overlooked production issues.
On localhost, developers may not have a properly configured mail delivery system.
After migration, verify:
If email does not arrive, investigate the server’s mail configuration and consider a properly configured transactional email service where appropriate.
Do not assume that PHP mail behavior on localhost will match production.
WordPress relies on scheduled tasks for certain functions.
After migration, verify that scheduled functionality works correctly.
Potential examples include:
Some hosting environments configure scheduled tasks differently.
For high-traffic or business-critical websites, scheduled task configuration deserves particular attention.
File permissions need to allow WordPress and the server to access necessary files without making everything unnecessarily writable.
Incorrect permissions can cause:
Avoid applying overly broad permissions simply because they make an immediate error disappear.
Use the hosting provider’s recommended permissions and ownership configuration.
Before migration, review your local installation.
Remove:
However, do not delete anything merely because it appears unfamiliar.
Some plugins or themes may contain configuration required by the site.
Review each component first.
When troubleshooting, follow a structured process.
Start with the question:
What changed between localhost and production?
Possible differences include:
This approach is more effective than randomly reinstalling WordPress.
When the website fails, logs can be more useful than visual symptoms.
Depending on your hosting environment, relevant logs may include:
A blank page, for example, provides little information.
A PHP error log can reveal the exact file and function where a problem occurred.
For production websites, do not leave verbose debugging output exposed to visitors.
Debugging should be handled carefully so sensitive information is not publicly displayed.
WordPress databases commonly use a table prefix.
A default installation may use something similar to:
wp_
but the prefix can be different.
The prefix is configured in:
wp-config.php
If your imported database uses a custom prefix, make sure the configuration matches it.
Otherwise WordPress may behave as though the database is empty or incorrectly configured.
An incomplete import can produce strange symptoms.
For example:
If you suspect an incomplete database import, inspect the database and compare the expected tables with the imported tables.
For important websites, do not continue making random configuration changes until you establish whether the database transfer was complete.
Once the website has been tested successfully, perform a cleanup.
Review:
Never leave database backups inside a publicly accessible website directory.
An SQL backup can contain sensitive information.
Store backups outside public web directories and use secure storage.
The first few hours and days after launch are important.
Monitor:
If the website is business-critical, establish monitoring rather than waiting for customers to report that something is broken.
The entire migration can be summarized as:
Plan → Back up → Prepare hosting → Create database → Export database → Upload files → Import database → Configure WordPress → Replace URLs → Configure DNS → Enable SSL → Refresh permalinks → Test → Monitor
Each stage has a specific purpose.
Skipping one may create problems later.
The biggest mistake beginners make is treating WordPress migration as simple file copying.
It is better understood as an environment transition.
A reliable sequence is:
A WordPress website may represent significant development time and business value.
A migration error can result in:
That is why professional migration should be treated as a deployment project rather than a simple upload task.
For businesses that do not have technical staff, working with an experienced WordPress development team can reduce the risks associated with database migration, URL replacement, server configuration, and production testing.
Even experienced developers can overlook small details.
Check these before declaring the migration complete:
A migration is successful only when the website works as a complete system.
There are several valid approaches.
Some workflows update the database after importing it into production.
Others use a migration tool that automatically handles URL replacement.
The important principle is to use a method that understands WordPress data structures.
Avoid making broad replacements without considering serialized data.
If you are uncertain, create an additional database backup before performing any URL replacement.
Changing from localhost to a real domain is normal.
Changing from one production domain to another is a more significant SEO operation.
For example:
oldsite.com
to:
newsite.com
requires careful redirect planning and search engine migration procedures.
A localhost-to-live migration usually looks like:
localhost/site
to:
example.com
That is generally a new production deployment rather than a domain-to-domain migration.
Developers can make migration more predictable by using version control and deployment workflows.
For example:
The database should not be treated exactly like application code because content and state change differently.
A mature WordPress workflow separates development code from production content whenever possible.
If you are new to WordPress, do not let the number of steps discourage you.
The underlying concept is simple.
Your website consists primarily of:
Files + Database + Configuration + Domain
The files contain the application and content assets.
The database contains structured website data.
The configuration tells WordPress how to connect to its environment.
The domain tells visitors where to find the website.
Once those four components are correctly connected, your localhost website can become a live website.
If you remember only a few things from this guide, remember these:
Never rely on a single copy.
Neither one alone represents the entire website.
This is one of the most common migration requirements.
Your live database is different from your local database.
Production websites should be securely configured.
This can solve many post-migration 404 problems.
The homepage loading does not prove the migration is complete.
Do not delete the development environment immediately.
Problems sometimes appear only after real visitors interact with the website.
Before considering your localhost-to-live migration complete, confirm all of the following.
Migrating a WordPress website from localhost to live hosting is a fundamental skill for anyone involved in WordPress development, website design, or digital publishing.
The process becomes much easier when you understand what is actually being moved.
You are not simply copying a website folder from one computer to another. You are transferring a complete WordPress application that consists of files, a database, configuration, URLs, media, plugins, themes, and environmental dependencies.
The safest workflow begins with a complete backup.
From there, prepare the production hosting environment, create the live database, upload the WordPress files, import the database, configure wp-config.php, and carefully replace localhost URLs with the production domain.
After that, configure DNS and HTTPS, refresh WordPress permalinks, and test the website thoroughly.
Do not stop when the homepage appears.
Test forms, menus, images, posts, pages, user accounts, email notifications, mobile layouts, redirects, SEO settings, and other business-critical functionality.
For larger websites, ecommerce stores, membership platforms, or websites that receive continuous traffic, migration should be treated as a planned deployment with staging, backups, testing, and a rollback strategy.
The most important principle is simple:
A successful WordPress migration is one where the live website behaves like the finished local website while remaining secure, accessible, functional, and ready for real visitors.
With a structured process and proper testing, moving WordPress from localhost to live hosting can be a predictable and manageable part of website development rather than a stressful last-minute task.
Get cost, timeline & technical suggestions within 24 hours.
