Website Handover Checklist Malaysia: What to Get Before Changing Web Designer

Quick answer: before changing your web designer, developer, freelancer or website agency, do not simply ask for the website username and password. A proper website handover should make sure your business has the access, information and documentation needed for the domain, DNS, hosting, admin panel, source code where applicable, database, backups, business email, contact forms, Google Analytics, Google Search Console, third-party integrations, software licences and important SEO configurations.

The purpose of a handover is not simply to make sure the new provider can open your website.

The real objective is to make sure your business can:

• retain control of its important digital assets,
• keep the website operating without unnecessary disruption,
• transfer responsibility safely to a new provider,
• recover the website if something goes wrong,
• avoid interrupting business email or customer enquiries, and
• reduce the risk of losing SEO value during technical changes.

If you are planning to change website provider, use this website handover checklist for Malaysia before the old account is closed, hosting is cancelled or access for the previous provider is removed.

What Is a Website Handover?

A website handover is the process of transferring the necessary access, responsibilities, documentation and control from one party to another.

It may happen when:

• a new website has been completed and the developer hands it over to the client,
• a business changes web designer or agency,
• website maintenance is transferred to a new provider,
• a website moves to different hosting,
• the website is being redesigned,
• the website is being rebuilt on another platform, or
• an employee or freelancer who previously managed the website leaves the company.

A proper handover should involve much more than:

“Here is the website username and password.”

A modern business website often depends on several separate systems.

You may have access to the CMS but still have no control over the domain. You may have hosting access but not the source code. You may be able to edit website content but have no access to Google Search Console or analytics.

That is why a website should be treated as a collection of connected digital assets rather than a single login.

Website Handover, Website Migration and Website Redesign Are Different

These terms are sometimes used as though they mean the same thing, but they describe different processes.

Process	What Changes?	Example
Website Handover	Access, ownership, documentation or responsibility	The old agency hands the website to a new provider
Website Migration	Hosting, infrastructure, platform, domain or URLs	The website moves to another server or platform
Website Redesign	Design, structure, UX and sometimes technology	An existing website is rebuilt with a new structure and design

A single project can involve all three.

For example, your business may change agency, migrate to different hosting and redesign the website at the same time.

The more things that change simultaneously, the more carefully the process should be planned.

Three Important Rules Before Changing Web Designer

1. Do Not Cancel the Old Provider Too Early

Do not terminate hosting, maintenance or the previous provider's accounts until you are confident that all required assets have been identified and transferred.

Closing an account too early could result in losing access to:

• website files,
• databases,
• backups,
• email systems,
• DNS records,
• licence information, or
• services that the website still depends on.

2. Create an Inventory Before Making Changes

Do not begin with the question:

“How do we move the website?”

Start with:

“What does this website currently depend on?”

Identify the complete website environment before changing it.

3. Make Sure the New Provider Has Access Before Removing the Old Provider

A safer sequence is:

1. Identify all accounts, systems and assets.
2. Obtain or verify the required access.
3. Create current backups.
4. Add the new provider where necessary.
5. Test the website and connected systems.
6. Complete the required transfer or migration.
7. Test everything again.
8. Only then remove access for the previous provider.

Avoid reversing this order.

Website Handover Checklist Malaysia: 15 Things You Should Secure

1. Domain Name and Registrar Access

Your domain is the main address customers use to reach your website.

For example:

yourbusiness.com.my

During the handover, establish:

• which registrar manages the domain,
• who can log in to the registrar account,
• which email address is used for account recovery,
• when the domain expires,
• who is responsible for renewal payments,
• whether automatic renewal is enabled, and
• which organisation or individual is recorded as the relevant domain contact where applicable.

For domains such as .my and .com.my, also make sure you understand who is recorded as the registrant and who controls the relevant administrative contact through the registrar.

Do not assume that your company controls the domain simply because the company name appears on the website.

An authorised person within the business should have an appropriate way to access and manage the domain.

2. DNS and Nameservers

The domain and DNS are related, but they are not the same thing.

DNS controls where your domain directs different types of internet traffic.

DNS records may control:

• the website,
• business email,
• subdomains,
• verification records,
• email authentication,
• third-party platforms, and
• CDN or security services.

Common DNS record types may include:

• A,
• AAAA,
• CNAME,
• MX,
• TXT,
• SPF-related records,
• DKIM,
• DMARC, and
• NS records.

Do not change nameservers blindly.

If the existing DNS zone contains MX records used for company email but the new provider copies only the website records, the website may continue working while business email stops receiving messages.

Before changing DNS:

• record the existing configuration,
• identify which records are still required,
• understand the current email configuration, and
• have a rollback plan if something goes wrong.

3. Hosting or Server Access

Next, identify where the website is actually hosted.

The website may use:

• shared hosting,
• VPS hosting,
• cloud hosting,
• managed WordPress hosting,
• static hosting,
• serverless infrastructure,
• a CDN, or
• another hosting environment.

Record information such as:

• hosting provider,
• account owner,
• billing responsibility,
• renewal date,
• server or project name,
• storage and databases being used,
• deployment method, and
• backup system.

If your website sits inside an agency account containing websites belonging to multiple clients, the agency may not be able to give you the entire account login.

In this situation, the previous and new provider need to determine an appropriate transfer method without exposing other clients' assets.

4. Website CMS or Admin Panel

If your website uses WordPress or another content management system, make sure you have an account with sufficient permissions.

Do not accept an editor-level account if future website maintenance requires administrator access.

Check:

• admin login URL,
• username or account email,
• user role and permissions,
• recovery email,
• two-factor authentication where applicable, and
• which other administrator accounts still exist.

Custom websites may use a purpose-built administration system, so the access model can be different.

5. Source Code and Repository

Not every website is managed entirely through a CMS.

A custom website may have source code stored in GitHub, GitLab or another repository.

If source code is required for future maintenance or development, identify:

• where the repository is hosted,
• who owns it,
• who has administrative access,
• which branch is used for production,
• the build process,
• the deployment workflow, and
• which environment configuration is required.

Do not assume that the files currently running on the server represent everything required to maintain the website.

Modern websites may require packages, build tools, configuration and deployment workflows to produce the production version.

If you are comparing different website technologies, read our WordPress vs Custom Website Malaysia guide for more information about maintenance, flexibility, scalability and ownership considerations.

6. Database, Website Files and Media

Dynamic websites normally use a database.

The database may contain:

• pages,
• blog posts,
• products,
• orders,
• customer accounts,
• form submissions,
• settings, and
• application data.

Your website may also contain files such as:

• images,
• PDF documents,
• videos,
• business documents,
• fonts,
• logos, and
• downloadable files.

Make sure the new provider understands where important files and data are stored before the previous provider is removed.

7. Backups and Recovery

Do not carry out a website handover without creating or confirming a current backup.

Backups are particularly important before:

• hosting migration,
• DNS cutover,
• major software updates,
• database migration,
• redesign launch, or
• termination of the previous provider.

Do not check only whether a backup exists.

Also establish:

• when it was created,
• what it contains,
• where it is stored,
• who can access it,
• how restoration works, and
• whether the recovery process has been tested where the website is business-critical.

If you need continued assistance with backups, updates, security and ongoing technical work after the handover, see Nibong Web Studio's website maintenance and support service.

8. Business Email and Email Delivery

This is one of the easiest areas to overlook during a website handover.

Your domain may also be used for business email addresses such as:

sales@yourbusiness.com.my

Business email may use the same provider as your website hosting or a completely separate service such as Microsoft 365, Google Workspace or another email hosting provider.

Before changing hosting or DNS, establish:

• who provides the email service,
• the relevant MX records,
• SPF configuration,
• DKIM configuration where used,
• DMARC configuration where used,
• active mailboxes,
• aliases and forwarding rules, and
• who has administrative access.

Do not assume that moving the website means the email system must also move.

If the email provider remains unchanged, make sure the website migration does not accidentally remove or overwrite email-related DNS records.

9. Contact Forms, SMTP and Notification Emails

A website can appear to migrate successfully while still losing customer enquiries because forms were not tested properly.

Identify how website forms send messages.

The website may use:

• server-based mail,
• an SMTP account,
• a transactional email service,
• an API, or
• a third-party form platform.

After handover, test important forms such as:

• contact forms,
• quotation forms,
• booking forms,
• newsletter forms,
• order notifications, and
• password-reset emails where applicable.

Do not test only whether the Submit button works. Make sure the actual message reaches the correct recipient.

10. Google Analytics and Tag Manager

If your website uses Google Analytics, make sure your business has its own appropriate access.

Where the platform allows it, the new provider should normally be added through its own user permissions rather than everyone sharing a single Google account.

Check:

• the correct Google Analytics property,
• account or property permissions,
• Google Tag Manager if used,
• measurement IDs,
• important conversion events, and
• tracking for forms or WhatsApp clicks where configured.

After the handover, confirm that data is still being collected correctly.

11. Google Search Console

Google Search Console is an important business asset when a website depends on organic search visibility.

Your business should have appropriate access rather than relying entirely on the previous agency's account.

Review:

• the correct Search Console property,
• verified owners,
• delegated owners or users,
• verification methods,
• submitted sitemaps, and
• performance data before any migration or redesign.

Before major changes, record a useful baseline such as:

• organic clicks,
• impressions,
• important search queries,
• important landing pages, and
• indexing status of key pages.

This gives you something to compare against after the transition.

12. SEO Assets and the Existing URL Inventory

If the new provider will redesign, rebuild or migrate the website, do not hand over only the visual design and written content.

Record important SEO assets as well.

These may include:

• existing URLs,
• page titles,
• meta descriptions,
• canonical URLs,
• XML sitemap,
• robots.txt,
• existing redirect rules,
• structured data where used,
• multilingual relationships such as hreflang where applicable,
• important internal links, and
• pages receiving organic traffic or backlinks.

If your URLs do not need to change, avoid changing them without a clear reason.

If URLs must change, create a mapping from each important old URL to the most relevant new destination.

Do not redirect every old URL to the homepage simply because it is easier.

For a wider technical review, use our Technical SEO Checklist Malaysia 2026.

13. Third-Party Integrations

Your website may depend on more external systems than are immediately visible.

Examples include:

• payment gateways,
• booking systems,
• CRM platforms,
• WhatsApp integrations,
• Google Maps,
• email marketing services,
• live chat,
• APIs,
• cloud storage,
• CDNs,
• security platforms, and
• social media integrations.

For every important integration, record:

• the provider,
• account owner,
• billing owner,
• access method,
• API key or token management where applicable,
• renewal date, and
• what would stop working if the service were cancelled.

14. Licences, Subscriptions and Recurring Costs

Your website may rely on paid software or external services.

Examples include:

• premium plugins,
• premium themes,
• font licences,
• stock image licences,
• page builders,
• email services,
• CDNs,
• backup services,
• security tools, and
• third-party APIs.

During the handover, ask:

• Who owns the licence?
• Can it be transferred?
• Will the website stop working if the subscription expires?
• How much does renewal cost?
• Who is responsible for renewing it?

Do not assume every plugin, theme or third-party service automatically becomes your property simply because it is used on your website. Review the applicable agreement or licensing arrangement where necessary.

15. Documentation, Training and Support Information

A good website handover should leave enough documentation for the new provider to understand how the website operates without having to guess.

Useful documentation can include:

• a list of accounts and service providers,
• website architecture,
• hosting information,
• deployment instructions,
• database information,
• backup procedures,
• DNS configuration,
• third-party integrations,
• custom functionality,
• scheduled tasks,
• renewal dates,
• known issues, and
• relevant support contacts.

For websites with an admin panel, basic training can also help your team understand how to:

• edit content,
• upload images,
• publish blog posts,
• manage products, and
• use important website functions.

Quick Website Handover Checklist Before Changing Provider

Asset	What to Confirm	Status
Domain	Registrar, registrant/contact, login and renewal	☐
DNS	Provider, nameservers and A/CNAME/MX/TXT records	☐
Hosting	Provider, account, billing and renewal	☐
CMS/Admin	Administrator access and account recovery	☐
Source Code	Repository, branch, build and deployment process	☐
Database	Database access and current export	☐
Media / Files	Images, PDFs and uploaded assets	☐
Backup	Current backup and recovery process	☐
Email	Provider, mailboxes, DNS and administrator access	☐
Forms	Form delivery, SMTP and notifications	☐
Analytics	Google Analytics access and tracking	☐
Search Console	Owner/user access and verification	☐
SEO	URLs, sitemap, redirects, metadata and baseline data	☐
Integrations	APIs, payments, booking, CRM and other services	☐
Licences	Ownership, renewal and transferability	☐
Documentation	Technical notes, known issues and processes	☐

A Safer Website Handover Process

A website handover is easier to control when it is completed in stages.

Phase 1: Inventory

List every important asset, account, provider and integration.

Do not change anything yet.

Phase 2: Verify Access

Make sure the business owner or authorised staff can access the important systems.

If the new provider requires access, use a separate user invitation or account where the platform supports it.

This is normally better than multiple people sharing a single password.

Phase 3: Backup and Record the Current State

Before migration or other major changes:

• create a current website backup,
• back up the database where applicable,
• save the existing DNS configuration,
• record current URLs,
• save important Search Console data, and
• document important configurations.

Phase 4: Transfer or Migration

Only after the inventory, access and backup stages are complete should the required changes begin.

The process might involve:

• account ownership,
• hosting,
• source repositories,
• DNS,
• databases,
• the CMS, or
• third-party accounts.

Phase 5: Verification

After the transfer, test the website from both a technical and customer perspective.

Check:

• homepage,
• service pages,
• mobile website,
• forms,
• WhatsApp links,
• business email,
• checkout or booking where applicable,
• analytics,
• Search Console,
• SSL,
• redirects, and
• important integrations.

Phase 6: Offboard the Previous Provider

Once the new provider has confirmed that critical systems are working correctly, review access belonging to the previous provider.

Possible actions include:

• removing old CMS users,
• removing hosting users,
• removing repository collaborators,
• removing Analytics permissions,
• removing Search Console access where appropriate,
• revoking old API keys or tokens where necessary,
• changing passwords that were previously shared, and
• reviewing active sessions and authentication methods.

Do not remove the previous provider so early that the handover cannot be completed properly.

Should You Change Passwords After a Website Handover?

For accounts where credentials were shared with the previous provider, changing passwords after the handover has been completed is sensible.

However, passwords are not the only form of access.

Modern websites may also use:

• individual user accounts,
• OAuth permissions,
• API tokens,
• deployment keys,
• SSH keys,
• service accounts,
• active sessions, and
• third-party integrations.

A complete offboarding process should therefore review all relevant access methods rather than changing only one password.

Avoid Sending Every Password Through Ordinary WhatsApp or Email

When a platform supports multiple users, it is generally better for the previous provider to add the business owner or new provider with appropriate permissions.

Services such as Analytics, Search Console and many hosting platforms support individual user access.

This provides several benefits:

• each person uses their own account,
• permissions can be controlled,
• access can be removed later, and
• the primary password does not need to be shared.

If credentials do need to be transferred, use an appropriate secure sharing method and avoid placing every password into an unprotected document available to too many people.

How Can Website Handover Affect SEO?

A change of website provider does not automatically affect Google rankings.

The main SEO risks arise when the handover also involves technical changes.

Examples include:

• URLs changing,
• the domain changing,
• migration to another platform,
• important content being removed,
• page titles changing,
• internal links changing,
• the sitemap changing,
• robots.txt changing,
• incorrect canonical URLs,
• missing redirects, or
• a staging noindex setting accidentally remaining on the production website.

If URLs Stay the Same

If the provider changes but your URLs, website structure and important content remain the same, the SEO transition is usually easier to manage.

You should still test:

• HTTP status codes,
• canonical URLs,
• robots.txt,
• XML sitemap,
• page rendering,
• analytics, and
• Search Console.

If URLs Change

If a redesign or migration creates new URLs, prepare a URL mapping document.

For example:

Old URL → most relevant new URL

For pages that have permanently moved, an appropriate permanent redirect such as a 301 redirect is commonly used according to the platform and server configuration.

After migration, test the redirects and update your internal links so they point directly to the new URLs.

If the Domain Changes

A domain change requires more planning because the entire website hostname changes.

It involves more than updating DNS.

Redirects, canonical URLs, Search Console, sitemaps, internal links and other important SEO signals should all be considered.

If you are redesigning your website while changing provider, read our Website Redesign Malaysia guide as well.

Avoid Changing Everything at Once Unless Necessary

Imagine a project where, on the same day, your business:

• changes website agency,
• changes hosting provider,
• changes domain,
• changes website platform,
• changes every URL,
• rewrites all website content, and
• changes the analytics setup.

If something goes wrong after launch, identifying the cause becomes much more difficult.

Where the project allows it, reduce the number of major variables changing at the same time.

Website Handover for WordPress vs Custom Websites

WordPress Websites

A WordPress handover may need to cover:

• WordPress administrator access,
• hosting,
• database access,
• website files,
• themes,
• plugins,
• software licences,
• backups,
• security configuration,
• SMTP, and
• scheduled jobs.

Custom Websites

A custom website may require more technical documentation, including:

• source-code repository,
• framework version,
• package dependencies,
• build instructions,
• environment variables,
• deployment platform,
• database schema,
• API integrations,
• serverless functions, and
• CI/CD processes.

The new provider needs to understand how the website is built before it can maintain the system safely.

E-Commerce Website Handovers Need Additional Checks

If your website sells products or accepts payments, the handover requires additional care.

In addition to the general checklist, review:

• payment gateway accounts,
• bank settlement details where relevant,
• order databases,
• customer accounts,
• inventory integrations,
• shipping integrations,
• transactional email,
• webhooks,
• tax configuration where used,
• refund workflows, and
• scheduled automation.

Do not make production changes without understanding the existing order and payment flow.

Website Handover Red Flags

Some situations deserve additional investigation before you proceed.

1. Nobody Knows Where the Domain Is Registered

The domain is a core business asset. Identify the registrar and establish how the authorised business owner can access it.

2. Important Accounts Use a Former Developer's Personal Email

This can make account recovery, billing and renewal difficult later.

3. There Is No Backup Before Migration

A high-risk change should not begin without a reasonable recovery option.

4. The New Provider Wants to Change DNS Without Checking Email

DNS controls more than the website. It may also affect business email and other services.

5. Every Existing URL Will Be Removed

If the website already has organic visibility or backlinks, URL changes need to be planned rather than treated as a cosmetic decision.

6. Nobody Has Search Console Access

This makes it more difficult to monitor Google performance and indexing problems before and after the change.

7. There Is No Documentation for Third-Party Systems

An overlooked integration can become a serious problem after the previous provider is no longer available.

8. The Old Provider Is Removed Before the New Provider Finishes Testing

A handover should provide enough overlap to resolve issues discovered during technical review.

What If the Previous Provider Will Not Give You Access?

Do not immediately assume that every website asset has been lost.

Separate the website into individual components and investigate them one at a time.

Ask specific questions:

• Who is the domain registrar?
• Who is the domain registrant?
• Where is DNS hosted?
• Where is the website hosted?
• Who has CMS administrator access?
• Is the source code available?
• Is a backup available?
• Who controls the Analytics property?
• Who is a Search Console owner?

You may control some parts of the website even if other components are still managed by the previous provider.

Also review relevant records such as:

• the original quotation,
• invoices,
• contracts,
• email correspondence,
• domain registration information, and
• terms covering hosting, licences or ownership.

If there is a genuine dispute about contractual rights or ownership, review the applicable agreement and seek suitable professional advice where necessary. Do not rely only on technical assumptions.

Website Handover After a New Website Is Completed

A handover is not only something that happens when leaving an old provider.

It should also form part of completing a new website project.

Before the project is considered complete, the business owner should understand:

• the live production URL,
• domain registrar,
• hosting provider,
• admin login URL,
• who has access,
• backup arrangements,
• renewal costs,
• maintenance arrangements,
• Google Analytics access,
• Google Search Console access,
• what the internal team can update, and
• what still requires a developer.

This is something worth asking about before choosing a web designer, rather than waiting until the project has already been completed.

After the Handover: Who Will Maintain the Website?

Once the website has successfully changed hands, the next question is:

Who is responsible from this point onward?

Clarify who will manage:

• domain renewal,
• hosting renewal,
• backups,
• software updates,
• security,
• content changes,
• technical issues,
• forms,
• analytics, and
• SEO.

If you want to understand the ongoing costs that may apply after moving to a new provider, read our guide to website maintenance costs in Malaysia.

Maintenance, Redesign or Rebuild?

A handover is also a good opportunity to review the condition of the existing website objectively.

Website Situation	Possible Approach
The website still works well but needs a new provider	Handover + maintenance
The website has several technical problems	Handover + maintenance / troubleshooting
The design and UX are outdated	Handover + redesign assessment
The website structure is fundamentally weak	Redesign or rebuild
The old platform is difficult to maintain	Migration or rebuild assessment
There is insufficient access or source material to maintain the existing website	Assess recovery versus rebuild

If the website is still suitable but needs ongoing technical care, see our website maintenance and support service.

If the website needs major changes to design, structure and user experience, see our website redesign service.

If the old platform is no longer practical and the website needs to be rebuilt, see our website development service.

Final Website Handover Checklist

Domain & DNS

• ☐ Registrar identified
• ☐ Registrant/contact information checked
• ☐ Appropriate business account recovery confirmed
• ☐ Renewal date known
• ☐ Nameservers recorded
• ☐ DNS zone recorded
• ☐ Email-related DNS records identified

Hosting & Website

• ☐ Hosting provider identified
• ☐ Hosting access available
• ☐ Administrator access available
• ☐ Source code available where required
• ☐ Repository access available where applicable
• ☐ Database available
• ☐ Images and website files available
• ☐ Current backup created

Business Systems

• ☐ Business email checked
• ☐ Contact forms tested
• ☐ SMTP/email delivery tested
• ☐ WhatsApp links tested
• ☐ Payment or booking systems tested where relevant
• ☐ Third-party integrations documented
• ☐ Licences and renewal requirements documented

Analytics & SEO

• ☐ Google Analytics access available
• ☐ Tag Manager access available if used
• ☐ Search Console access available
• ☐ Existing URL inventory saved
• ☐ Sitemap checked
• ☐ Robots.txt checked
• ☐ Existing redirects documented
• ☐ Important SEO data recorded before migration

Security & Offboarding

• ☐ New provider has tested the website
• ☐ Current backup can be accessed
• ☐ Old user accounts identified
• ☐ Shared passwords changed where appropriate
• ☐ Old tokens and keys reviewed
• ☐ Previous provider removed only after handover is complete
• ☐ Emergency contact and recovery process understood

Frequently Asked Questions About Website Handover

What should I ask my old web designer to provide?

At minimum, identify and obtain the required access to the domain, DNS, hosting, CMS or admin panel, backups, database and website files. Where relevant, you may also need source-code repository access, Analytics, Search Console, third-party services, licences and technical documentation.

Do I need to transfer my domain when changing web designer?

Not necessarily. You can change web designer without changing domain registrar. What matters is that your business has appropriate control over the domain and that the new provider receives the access required to perform its work.

Do I need to change hosting when changing web designer?

Not necessarily. If your existing hosting remains suitable and the required access is available, it may be retained. Hosting migration should normally have a clear technical, operational or commercial reason.

Will a website handover affect my Google rankings?

Changing provider alone does not automatically affect rankings. The greater SEO risks arise when the handover also changes URLs, domain, content, platform, redirects, rendering or other technical configurations.

Should I keep all my existing URLs?

If existing URLs remain suitable, keeping them can reduce migration complexity. If URLs must change, map important old URLs to their most relevant new destinations and implement the appropriate redirects.

What happens if I do not have the website source code?

It depends on how the website was built. Some CMS websites can be maintained without a separate source-code repository, while a custom application may require source code and build configuration for future development. The new provider should assess the actual architecture before making a recommendation.

Is a hosting backup enough?

A hosting backup can be extremely useful, but you should understand what it contains and how restoration works. For an important website, do not assume that a backup is usable without understanding the recovery process.

Should I change passwords after the handover?

Review and rotate credentials that were previously shared with the old provider once the handover is complete. Also review user accounts, API keys, tokens, SSH keys, active sessions and other relevant forms of access.

Who should own Google Analytics and Search Console access?

Your business should retain suitable access to data relating to its own website rather than depending entirely on the provider's login. Agencies and developers can be granted their own permissions as required.

What is the difference between website handover and migration?

A handover transfers access, responsibility and documentation. A migration moves the website or part of its infrastructure, such as hosting, platform, domain or URL structure. A handover can take place without a migration.

Should I redesign the website when changing provider?

Not automatically. If the website structure and user experience are still suitable, changing provider alone is not a reason to redesign it. Consider redesign when the main problems involve outdated design, poor mobile usability, weak navigation, poor conversion flow, obsolete technology or unsuitable content structure.

Conclusion

A proper website handover involves much more than receiving a ZIP file or a few passwords.

It is the process of making sure your business understands and can control the important components required to keep the website operational.

Before changing your web designer or website provider, make sure you have reviewed:

• domain,
• registrar access,
• DNS,
• hosting,
• CMS/admin access,
• source code,
• database,
• files and media,
• backups,
• business email,
• forms and SMTP,
• Analytics,
• Search Console,
• SEO configuration,
• third-party integrations,
• software licences,
• renewal costs,
• technical documentation, and
• security access.

Most importantly, do not terminate the previous provider until the new provider has the necessary access, current backups are available and the website has been tested properly.

If you are planning to change website provider and are unsure whether your current website should be maintained, redesigned or rebuilt, you can contact Nibong Web Studio and share your existing website so the situation can be discussed first.