How to transfer your website to a new developer (without losing anything)

The moment a business decides to change web developers is usually the moment it discovers how little of its own digital setup it can see: who holds the domain, where the email lives, whose name is on the hosting bill. This guide is the complete handover: every account to inventory, the safe transfer sequence and what to do when the old developer is uncooperative or has vanished. Two rules run through all of it. Add, verify, remove, in that order. And do not migrate systems just because you are migrating relationships.

The straight answer: inventory first, transfer second

Before the old developer is removed from anything, the business should know what systems exist, which accounts own them, who has administrator access, which services renew automatically, what data needs backing up, which licences belong to the agency rather than to you and what the new developer actually needs. Every messy handover we have ever untangled skipped this step and went straight to changing passwords.

Changing developer, changing hosting and migrating a website are different things

These get bundled together and they should not be. Changing developer means the site stays exactly where it is and only the people maintaining it change. Changing hosting means the existing website is copied to a different server. A website migration can involve a new platform, new URLs, a redesigned site or substantial architecture changes. And a domain transfer changes which registrar manages the domain licence, which does not automatically move the website or the email.

For Australian .au domains, auDA, the administrator of the .au namespace, separates two different processes again: transferring the domain licence to another registrar and transferring the licence to another registrant entirely. Registrar transfers use an authorisation code, sometimes called an EPP code or domain password and auDA runs an official password recovery tool for registrants who have lost theirs. Knowing which of these processes you actually need saves days of confusion.

First, build a website ownership and access register

One spreadsheet, one row per system. For each: the platform, the account URL, the account owner, the business administrator, the current developer's access, the billing owner, the renewal date, the recovery email and who holds the 2FA. It takes an hour and it converts the handover from an argument into a checklist. Here is the shape:

The rows where the business column says no are your priority list. Everything else in this article works through them one by one.

The website ownership stack. Each layer is a separate system with its own account and the business should know its standing on every one: owner, administrator, user or licensee.

Everything you should collect before changing web developers

Seventeen systems, roughly in order of how much damage losing them causes. Most businesses will not have all seventeen. Every business has more of them than it thinks.

1. Domain name

Record the registrar, the registrant, the account login, the renewal date, the billing method, the recovery email, the DNS nameservers and the authorisation code if a registrar transfer is planned. Above all, confirm who the registered holder actually is. The catastrophic version of this story is the business that discovers its primary domain exists only inside the developer's personal account and it is common enough that checking should be your first task, not your last.

2. DNS

DNS, the system that points your domain at services, deserves its own line because it controls more than the website: email routing, verification records, subdomains, CDNs and third party apps all hang off it. Before changing anything, export or screenshot the complete DNS zone: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC and every verification record.

3. Hosting account

Record the provider, plan, billing owner, login, server location where it matters, storage, backup arrangements, staging environment, SSL, database access, SFTP or SSH access, any CDN and how it relates to DNS. Then ask the question agencies skip: do we actually need to move hosting? If the existing hosting performs well, is secure, is properly supported and the business can access it, the new developer can simply work with it. If a move is genuinely warranted, choose hosting worth moving to rather than whatever the new provider resells by default. Changing the person managing the website does not automatically require changing the server running it.

4. CMS administrator access

Whether the site runs on WordPress, Shopify, Webflow, Squarespace or Wix, the business needs an appropriate administrator or owner level account of its own. Do not inherit the old developer's login; create individual, named accounts. Before anyone is removed, verify the new administrator can log in, edit pages, upload media, manage users, manage plugins or apps where appropriate, change settings and reach the integrations.

5. Website files and database

For a typical WordPress site, a complete recoverable backup has two parts and WordPress's own developer documentation is explicit about it: the website files and the database are separate systems and you need both for a full restore. Collect the full site files, a database export, the uploads, the theme and child theme, plugins, configuration and any custom code. Create a dated snapshot, something like Pre developer transfer, 12 August 2026 and store it somewhere the business or the incoming provider controls. Our full guide to backing up a website properly covers the how; the when is now, before anything changes.

6. Current transactional data

If the site handles orders, memberships, bookings, customer accounts, course activity or subscriptions, the data keeps changing while you copy it. A brochure site can be copied once; an active store may need a maintenance window, a second delta migration, an order freeze or a reconciliation pass. This is a solved problem when it is planned and a nightmare when it is discovered on launch night, which is why how we handle websites for online retailers treats the data cutover as its own project stage.

7. Business email

Work out whether email runs on Google Workspace, Microsoft 365, the hosting provider or another service and record the provider, administrator account, billing and the MX, SPF, DKIM and DMARC records. Do not assume email is part of the website. It usually shares the domain while living on a completely separate system and treating them as one thing is how migrations kill inboxes.

8. Contact form and email delivery setup

Record the form plugin or platform, recipient addresses, the SMTP or sending service, API credentials, autoresponders, CRM connections, spam protection and where submissions are stored. Forms fail silently, which makes them the sneakiest casualty of any transfer. After handover, test a standard enquiry, a mobile submission, the confirmation message, the internal notification and the CRM delivery. If patient or health information flows through those forms, the stakes are higher again, which is a routine part of websites that handle patient information.

9. Google Analytics 4

The business should keep the existing GA4 property and its history, not abandon years of data because the agency changed. Confirm the property and data stream, confirm a business administrator exists, add the new provider as a user and verify the key events still fire. The lazy pattern to refuse is new agency, new property, unless there is a genuine technical reason. If the current setup is murky, what GA4 should look like for a small business is the reference for getting it structured under business control.

10. Google Search Console

Search Console distinguishes verified owners, who proved ownership with a token, from delegated owners, full users and restricted users and a property must keep at least one verified owner or nobody has access at all. The business should be a verified owner in its own right, ideally on the domain property. Before the former agency is removed, confirm business ownership, add the new provider, review the existing owner list and check the sitemap and performance data are intact. Our Search Console setup walkthrough covers verification from scratch if the business was never an owner to begin with.

11. Google Tag Manager

This one is special because Google's own guidance is unusually direct: keep more than one administrator and make sure the account is managed by someone within your organisation, not an external agency. There is a hard reason behind the politeness: a Tag Manager account or container with no administrator at all is automatically deleted. Before handover, confirm a business administrator, add the new provider, export the container as a backup and document the tags, triggers and variables.

12. Advertising and marketing platforms

Review Google Ads, Meta Business Portfolio, LinkedIn, Microsoft Ads, email marketing, the CRM, call tracking and review systems. Your web developer may not manage these, but the website's code connects to them through pixels and conversion tags, so document the account IDs, pixels, conversion actions and API connections. The Google Ads account is worth special attention: the business should hold admin on its own account, with whoever manages the Google Ads account working inside it as a user, the same principle as Tag Manager.

13. Design and source files

Depending on the project: Figma files, Adobe files, logo assets, SVGs, icon sets, brand guidelines, illustrations, image masters, wireframes, prototypes. One legal nuance matters here and it matters enough to say carefully: do not assume that paying for the website means every source file and every piece of underlying IP automatically belongs to you. Australian government guidance treats IP as an asset whose ownership, assignment and licensing should be spelled out in the agreement and absent that, the creator can be the default owner. Check the actual contract before making demands and if you have not signed with the new provider yet, the questions to ask a new developer before signing will make sure the next contract answers this properly.

14. Source code and repository access

For custom development, ask whether code lives in GitHub, GitLab, Bitbucket or a private repository and collect repository access, the branches that matter, deployment instructions, CI and CD configuration and environment documentation. If the project is actively maintained through version control, receiving only a ZIP of the current production files is receiving a photocopy of a living document. Get the repository.

15. Themes, plugins, apps and software licences

Document every piece of paid software: what it is, who owns the licence, what renewal costs, when it expires, whether it can transfer and what would replace it. Premium WordPress plugins, themes, Shopify apps, commercial fonts, stock photography, API subscriptions. Here is the part that keeps handovers civil: the former developer may legitimately own an agency licence covering your site. That is not them withholding your website. It means the new provider buys a fresh licence, replaces the component or moves you to a subscription in your own name. Website ownership and third party software licensing are not the same thing.

16. Third party integrations

Audit the CRM, accounting, booking, ecommerce, inventory, payment gateways, shipping, forms, email, live chat, customer portals and any APIs. For each: who owns the account, where the credentials live, how the connection works, who pays for it and whether it is documented anywhere at all. Payment gateways deserve first attention, because they are the integration that stops revenue when it breaks.

17. Existing documentation

Request the architecture notes, deployment instructions, server notes, plugin list, custom code documentation, API documentation, scheduled tasks, maintenance history, known bugs and renewal list. A small brochure site may have none of this and that is fine. For custom systems, missing documentation is itself a risk factor: budget the new provider some discovery time to map what they have inherited.

Step by step: how to transfer a website to a new developer

With the inventory done, the actual transfer is a sequence. The order is the protection.

Step 1: choose the new developer first

Do not terminate the old relationship before knowing who is taking over, what access they need, whether hosting will change, whether licences need replacing and what technical surprises exist. A good incoming provider will help interpret the handover inventory and how they handle that interpretation is your first look at how they work.

Step 2: review the existing contract

Look for termination notice periods, hosting terms, IP ownership, licence terms, outstanding invoices, handover obligations, data retention and termination fees. Do not assume what either party legally owns; the contract is the referee. For disputed or high value situations, get legal advice before acting, not after.

Step 3: create the asset and access register

The register from earlier in this article, with every row marked: confirmed, missing, needs transfer, needs replacement or not applicable. The missing rows are the work.

Step 4: take a full backup

Before passwords change, before DNS changes, before any hosting migration, before any licence is removed. For WordPress that means files and database both, per the platform's own documentation. A backup taken after things start changing is a photograph of the accident.

Step 5: add the new developer without removing the old one yet

Give the new team a named CMS account, hosting access, analytics, Search Console, Tag Manager and the integrations they need, each in its own credential. Do not email one master password that opens everything; that is how access sprawl started last time.

Step 6: verify the new developer can access everything

Have them confirm, in writing, access to the website, database, server, domain and DNS where needed, staging, repositories, analytics, tracking, integrations and backups. A checklist reply takes them ten minutes and turns assumed access into confirmed access.

Step 7A: if the website is staying on the same hosting

The handover may be genuinely simple: new developer access, a fresh backup, a licence review, documentation, monitoring and removal of the former provider once everything is confirmed. No DNS change may be needed at all. This is the quiet case and it is more common than the industry admits.

Step 7B: if the website is moving to new hosting

The sequence: provision the new hosting, copy the website, copy the database, configure the environment, stand up a staging or temporary URL, test the site, test the forms, test the integrations, confirm SSL, prepare the DNS change, switch the web records, monitor and retain the old hosting temporarily. That last item is not optional. Do not cancel the previous hosting before the migrated site is confirmed working, because the old server is your only rollback.

Step 8: protect email during DNS changes

Before touching DNS: export the existing zone and identify the MX, SPF, DKIM, DMARC and third party TXT records. If only the website server is changing, often only the web records need to change and the rest of the zone should be left exactly alone. Do not rebuild the entire DNS zone to move one A record.

Step 9: run the transfer QA

Test the website: homepage, navigation, service pages, media, downloads, mobile. Test the forms: enquiry, autoresponder, delivery, CRM. Test ecommerce end to end: cart, checkout, payment, inventory, confirmation. Test SEO: URLs, canonicals, robots.txt, sitemap, redirects, Search Console. Test tracking: GA4, Tag Manager, Google Ads, Meta, call tracking. Test email: incoming, outgoing and the authentication records. It is the same discipline as a launch, so run the same QA we run on launches and treat any skipped row as a risk you chose.

Step 10: keep the old setup available during the transition

Retain the former hosting and environment until DNS is resolving correctly everywhere, the site is stable, forms work, email works, transactions work, the new backups are running and the logs show nothing unexpected. Only then cancel the old environment. There is no universal number of days; there is a checklist and the old setup stays until the checklist is green.

Old environment  →  migration bridge  →  new verified environment

Do not cut the rope too early. The old setup and old access come down only after the new side has carried real traffic, real forms and real email.

Step 11: remove the former developer's access

After successful handover and only after: review the CMS, hosting, domain and DNS, GA4, Search Console, Tag Manager, repositories, CRM, forms, backup services, CDN and third party apps. Rotate any credential that was shared, known to several people or stored loosely. One Search Console subtlety worth knowing: removing a previously verified owner is not complete until their leftover verification tokens are removed too or they can quietly reverify later. And pause before deleting accounts tied to historical attribution, ownership proof or licensing; understand the consequence first.

Step 12: secure the new setup

Review the administrator list, enable 2FA everywhere, remove dormant users, update recovery emails, move billing to the business, verify the new backups actually run, document renewal dates and test a restore. Then treat the handover as the perfect excuse for reviewing WordPress security after a handover, because access changes are exactly when security assumptions go stale. Once control is settled, it is also worth auditing the website you have just taken control of, since you now own whatever you find.

How to know the website transfer is actually complete

The owner test. For the domain: can we log in, renew it, change DNS and recover the account? For hosting: can we contact support, see billing, download backups and migrate away if we choose? For the CMS: can we create users, edit pages and install approved software? For tracking: are we administrators of GA4, Search Console and Tag Manager? For files: do we hold a recoverable backup, the agreed design and source files and repository access where relevant? And for operations: do email, forms, checkout, bookings, the CRM and tracking all still work?

Inventory → Backup → Add new access → Verify → Migrate if needed → QA → Remove old access → Document

The safe handover sequence. Every messy transfer we have untangled ran these steps in a different order, usually starting with the second last one.

Complete website handover checklist

Domain and infrastructure

Website

Email

Marketing and tracking

Assets and software

Documentation

What to do if your current developer refuses to hand things over

First, resist the framing. Not every difficult handover is a hostage situation. There may be legitimate disputes underneath: unpaid invoices, licensing, contractual scope, IP or genuine confusion about which accounts belong to whom. A calm, procedural approach resolves most of these; heat resolves none of them.

Step 1: work out what is actually missing

Make a specific list. Not give us everything, which is unanswerable, but: WordPress administrator access, hosting login, registrar access, GA4 administrator access, Search Console ownership, a current database backup, the agreed Figma files. Specific requests get specific answers and they read very differently if the matter ever escalates.

Step 2: review the contract

Check the IP clauses, access and handover obligations, hosting terms, termination provisions, licence terms and any outstanding payment. Australian government guidance is consistent on this: IP ownership clauses determine who holds rights to work created in a contractor relationship. Read before claiming.

Step 3: recover the accounts the business already owns

Reset business owned email. Recover the registrar account. Recover hosting where the account is in the business's name. Verify Search Console through the domain. Add access through existing business administrators. For .au domains, auDA provides official processes for registrar transfers and for recovering the domain authorisation code. Use official recovery channels only; never try to bypass a provider's security, which converts your recovery problem into your conduct problem.

Step 4: contact the underlying provider

Where an account is genuinely registered to the business but access is lost, the registrar, host or platform can often help, with proof of identity, business ownership, domain control and billing. Be realistic: no platform will override an existing registrant record or settle a contract dispute on the phone.

Step 5: put the request in writing

Business name, website, contract reference, the specific assets and access needed, a proposed transfer date and the new provider's contact if appropriate. Factual, dated, polite. No threats, no accusations, no demands for passwords without context. This document is for the outcome you want and for the record you may need.

Step 6: resolve outstanding commercial issues

If payment is genuinely disputed, reconcile the invoices, identify the disputed scope, review the contract and document your position. A handover article cannot settle contractual rights and pretending otherwise wastes weeks.

Step 7: get legal advice if ownership is genuinely disputed

Particularly where the dispute involves valuable custom software, domain control, proprietary code, business critical data, substantial project value, threatened deletion or contested IP.

What if the old developer has completely disappeared?

Different situation, different method: work outward from the systems the business still controls, in this order: domain, DNS, email, hosting, CMS, analytics, backups. The domain is the master key, because provable domain control helps recover or verify almost everything else, including Search Console ownership. Then use each provider's official recovery channel.

If you control the hosting, files, database and domain, the website can usually be handed to a new provider without the previous developer participating at all. The hard case is where essential custom source code or systems exist only inside a third party account nobody can reach; that is when specialist technical or legal help earns its fee.

What if you need to change developer immediately?

Security incident, site down, developer unreachable or a relationship on fire. Priorities compress. Priority one: protect the domain, DNS, hosting and backups, because everything else can be rebuilt from those. Priority two: preserve the website files, database and logs. Priority three: keep email, forms and ecommerce running. Only then restructure users and licences.

Two disciplines hold even in an emergency. Avoid making unnecessary changes during an incident, because every change destroys information about what happened. And if compromise or malicious activity is suspected, preserve the evidence before cleaning up; you may need it.

Should you redesign the website while changing developer?

Usually not automatically. Changing developer already changes accounts, responsibilities and possibly hosting; stacking a full redesign on top multiplies the moving parts and the ways to lose something. Combine them when the site is structurally obsolete, the platform needs replacing after comparing platforms before committing to a migration, a major business change is underway or a migration is inevitable anyway. Separate them when the site currently works, the urgent priority is regaining control, performance is stable or the redesign requirements are still vague. Working out whether the website needs a redesign at all is its own decision with its own evidence and if the rebuild is genuinely on the cards, put a number on the rebuild before combining the projects so the decision is costed, not assumed. When the relaunch does come, planning a relaunch when the time comes picks up where this article ends.

That last row is the whole reason keeping your SEO intact through a hosting move exists as its own checklist and why it is worth having organic performance baselined before the move: without a before, nobody can prove the transfer went cleanly or catch it early if it did not. The mechanics of how organic visibility is actually built and kept explain why URLs and internal structure deserve this much respect during any change of hands.

Common website handover mistakes

Removing the old developer before adding the new one

Remove, hope, add. The order that turns a handover into a recovery project.

Cancelling hosting too early

The old server is the rollback. It stays until the new environment has proven itself under real traffic.

Changing nameservers without copying email records

The classic. Website moves, inboxes die and nobody connects the two for a day and a half.

Assuming the domain and website are the same system

The domain is a licence, the website is files on a server. They can and often should, move separately or not at all.

Creating a new GA4 property because access recovery feels difficult

Ten minutes of access recovery versus years of deleted history. Recover the property.

Losing historical Search Console access

The performance record of your domain lives there. Keep the property and keep the business verified on it.

Forgetting Tag Manager

The invisible one, until conversions stop recording. Remember that a container with no admin at all eventually gets deleted by Google.

Copying WordPress files without the database

Half a backup. The files are the furniture; the database is everything you ever wrote.

Forgetting form SMTP settings

Forms that submit but never deliver are worse than forms that error, because nobody notices for weeks.

Assuming agency plugin licences belong to the client

They often legitimately do not. Budget for replacements instead of arguing about them.

Moving every system simply because the developer changed

New custodian does not mean new house. Keep what works.

Not testing checkout or bookings

The only pages that directly make money are the ones most often skipped in transfer QA.

Forgetting CDN or firewall access

Cloudflare and friends sit in front of everything. If nobody can log in, nobody can fix DNS, caching or security rules.

Sharing one master password with the new provider

Named accounts, individual credentials, least privilege. The cleanup from shared passwords is exactly what you are living through now.

Removing the previous hosting before DNS has settled and QA is complete

A variation on cancelling early and just as final.

Starting a redesign before securing control of the existing website

Building an extension on a house you cannot yet enter. Control first, construction second.

Our honest take: a good website handover should be boring

A developer handover should not feel dramatic. There should be a list of systems, clearly defined owners, separate user accounts, a current backup, documented licences, a transfer date and a QA checklist and then the new team quietly takes over. When it feels like a heist movie instead, the problem started years earlier.

Good agencies make themselves replaceable at a technical level. They earn retention through the quality of the work, not by being the only people who know the passwords. It is the same standard we argued for when choosing a provider and it is how we run ongoing website development and support ourselves: named accounts, documented licences, the client verified on their own properties and a handover file that exists before anyone asks for it. Boring, by design.

FAQs

How do I transfer my website to a new developer?

Inventory every system and account, take a full backup, add the new developer's access, verify they can reach everything, migrate hosting only if genuinely needed, run QA, then remove the old developer's access and document the result. Add, verify, remove.

What access does a new web developer need?

Typically a named CMS administrator account, hosting access and user or admin access to GA4, Search Console and Tag Manager, plus any repositories and integrations they will maintain. Each in its own credential, not one master password.

Can I change developer without changing hosting?

Yes and it is often the best path. If the hosting performs well, is secure and the business can access it, the new developer simply works with it. No DNS change may be needed at all.

Do I need to transfer my domain when changing developer?

No. The domain licence and the website are separate systems. Transfer the registrar only if there is a reason to; what matters is that the business controls the registrar account either way.

Who should own my website domain?

The business, as the registrant, in an account the business can log into and recover. It is the one asset on this list that cannot be rebuilt if it is lost.

What should be included in a website handover?

Access to the CMS, hosting, domain and DNS, analytics, Search Console, Tag Manager and integrations, a files and database backup, agreed design and source files, a licence list with owners and renewals and documentation.

How do I transfer a WordPress website to another developer?

If hosting stays, create the new developer a named administrator account and hand over documentation. If hosting changes, copy the files and the database to the new environment, test on staging, then repoint the web DNS records.

Do I need both WordPress files and the database?

Yes. WordPress's own documentation is explicit that files and database are separate and both are needed for a full restore. Files without the database is a theme without the content.

Can changing website hosting affect email?

Yes, when DNS is changed carelessly. If nameservers move without the MX and related records being recreated, mail stops. If only web records change, properly handled, email never notices.

What happens to my Google Analytics when I change agency?

Nothing should. Keep the existing GA4 property and its history, keep a business administrator on it, add the new agency as a user and remove the old one. Creating a new property throws away your own data.

Should I create a new Search Console account?

No. Keep the existing property and its history, make sure the business is a verified owner and add the new provider. If the old provider was the only verified owner, verify the business first, then tidy the owner list and leftover tokens.

What happens to plugin licences when I change WordPress developer?

Agency held licences often stay with the agency, legitimately. The new provider buys replacements or moves you to licences in the business's name. Budget for it rather than disputing it.

What if my web developer will not give me access?

Make a specific written list of what is missing, review the contract, recover the accounts the business already owns through official channels and escalate to the underlying providers. If ownership is genuinely disputed, get legal advice.

What if my old developer registered my domain in their name?

Check the registrant record, then review your contract and get advice if the registrant is wrong. For .au domains there are formal auDA processes for changing registrant and recovering authorisation codes, but a genuine registrant dispute is a legal question, not a support ticket.

Can a web developer legally keep my website files?

It depends on the contract. Contractor created IP can default to the creator absent an agreement saying otherwise and some components are licensed rather than owned by anyone. Read the agreement and get legal advice where the value justifies it.

Should I redesign while changing developers?

Usually regain control first and redesign second. Combine them only when the site is structurally obsolete, the platform must change or a migration is happening regardless.

How long should I keep my old hosting after migration?

Until DNS resolves correctly everywhere, the site is stable, forms and email work, transactions succeed and new backups are running. It is a checklist, not a number of days.

When should I remove my old developer's access?

Last. After the new developer's access is verified, the backup is confirmed, QA has passed and the transition period is over. Then remove access everywhere, rotate shared credentials and clear leftover Search Console verification tokens.

Next steps: pick your path

Path 1: you are planning a change. Build the ownership and access register before contacting anyone. Once ownership, access and backups are confirmed, the actual handover becomes an afternoon of admin instead of a month of archaeology.

Path 2: you are mid transfer or stuck. Find your position in the twelve steps and hold the two rules: add, verify, remove and keep the old environment until the new one has proven itself. If things are stuck on the human side, the written request in the disputes section is your next move. For the bigger picture of running the site well once it is yours again, our full website design and development guide covers the whole lifecycle and the privacy side of handling website customer information matters here too, because form submissions and customer records are personal information whichever server they sit on. While you are budgeting the new arrangement, what ongoing website support should cost and the licence and software costs that hide in websites will keep the new provider's quote honest.

Path 3: you want it handled. We can review an existing setup, identify what genuinely needs transferring and take over a website without replacing systems that are already working. Tell us where the handover is stuck and we will map the shortest safe path out, including the awkward conversation with the old provider if you would rather not have it yourself.

Sources and further reading

auDA: transfer your .au domain name , the official processes for changing registrar and changing registrant, including authorisation codes and password recovery.

Google Tag Manager: considerations before you install , Google's recommendation for multiple administrators and in organisation account ownership and what happens to accounts with no admin.

Google Search Console: managing owners, users and permissions , verified and delegated owners, permission levels and handling leftover verification tokens.

WordPress developer handbook: backups , why a complete WordPress backup needs both the files and the database.

Australian government guidance on IP ownership in contracts , intellectual property as a business asset and why ownership arrangements belong in the agreement.

General information only. Rules vary by situation, particularly around advertising claims, privacy, reviews and consumer law. If you're unsure about compliance, get professional advice.