Review the current domain, hosting, and SSL certificate options against that record, then request written confirmation of the exact scope needed by the project.
Separate the four components
| Component | Its job | Access to record | What a change can affect |
|---|---|---|---|
| Domain | Provides the name people use to reach an internet address. | Registrant data, registrar account, renewal contact, and transfer access. | Renewal, delegation, and control of the name. |
| DNS | Connects names to website, mail, and other service records. | DNS provider, nameservers, zone editor, and record history. | Website routing, mail delivery, validation, and third-party services. |
| Hosting | Runs or stores the website application and data. | Control panel, files, database, logs, and backup access. | Application operation, deployment, capacity, and recovery. |
| TLS certificate | Helps establish an authenticated, encrypted HTTPS connection for covered names. | Certificate issuer or automation, private-key owner, and renewal process. | HTTPS availability and certificate warnings. |
ICANN explains that DNS connects a domain name to an internet address. This means that changing nameservers can affect more than the website. Mail records and validation records may live in the same DNS zone.
For a basic hosting explanation, read what hosting is and who needs it.
Check market targeting and transfer rules
Google describes a country-code top-level domain such as .lv as a strong signal that a site is intended for a particular country, not as a ranking guarantee. Choose the extension from the intended audience, naming policy, control, and portability rather than assuming that it improves rankings.
For covered generic top-level domains, ICANN transfer rules can include locks after initial registration, a previous transfer, or a change of registrant. Obtain the AuthInfo code when the TLD process uses one and verify transfer eligibility before changing contact details. .lv follows NIC.LV policy: distinguish transfer of the holder's right to use the name from transfer of registrar management, and follow the required holder-authorization process. A registrar transfer and a DNS-hosting change are separate. Inventory nameservers, zone records, DNSSEC or DS state, and email records before changing either.
Mistake 1: choosing a name without an operational check
A short, pronounceable name can still create trouble if it is ambiguous when spoken, easy to mistype, or too close to another organization. Write it, say it aloud, type it on a phone, and check how it appears in an email address. Review relevant trademark and naming requirements with an appropriate adviser; domain availability alone does not grant rights to a name.
Decide whether important variants should be registered and redirected, but avoid buying variants without an owner and renewal purpose. Record the final spelling and the primary domain used in canonical URLs and email.
Mistake 2: leaving domain ownership and renewal unclear
The organization should know which account holds the domain, who can approve transfers, which email receives renewal notices, and how access is recovered if a staff member leaves. Do not register a business domain only in an employee's or supplier's personal account without a documented control arrangement.
Keep a domain register with the registrar, account owner, renewal date, auto-renewal status, payment owner, nameservers, DNS provider, and recovery procedure. Test access before a migration or staff handover.
Mistake 3: selecting hosting from price or disk space alone
Start with application requirements: supported runtime and database versions, storage growth, traffic pattern, scheduled tasks, mail behaviour, deployment access, logs, backups, and recovery targets. A plan with more disk can still be unsuitable if the application cannot run or the required access is absent.
Clarify who performs CMS and plugin updates, server maintenance, monitoring, incident response, migrations, and restores. Compare the current hosting scope against the written checklist, not against a generic label.
Mistake 4: treating TLS as a single checkbox
TLS secures HTTP connections as HTTPS. The certificate must cover the names users visit and must renew before expiry. Let’s Encrypt documents that HTTP-01 and DNS-01 use different validation methods, and that DNS-01 can be used for wildcard certificates.
List the required names, such as the main domain, www, and any application subdomains. Confirm who controls DNS, who owns the private key or automation, how renewal is monitored, and what happens if validation fails. Use the SSL certificate overview to compare current coverage and validation options, then verify the exact certificate scope before ordering.
Mistake 5: having no migration, backup, or exit plan
Before launch, document how to export files, databases, DNS zones, certificates, and mail data. Define the backup scope, retention, location, encryption where required, and restore-test schedule. The article on website backups explains why the restore process belongs in the plan.
For a move, inventory every DNS record, lower time-to-live where appropriate, preserve the previous environment, and test the new site with controlled DNS or a hosts-file method. Check forms, login, payment or enquiry flows, mail delivery, redirects, analytics, robots directives, canonical URLs, and HTTPS before closing the rollback window.
Questions before purchase
Can the domain and website use different providers?
Yes. Record which provider controls the domain registration, DNS zone, website hosting, and mail. Separate providers make documentation and access control more important.
Does changing nameservers move the website only?
No. A nameserver change delegates the DNS zone. Recreate and verify website, mail, validation, and third-party records before switching.
Which TLS certificate should I choose?
Choose from the hostnames that need coverage and the validation process your organization requires. Confirm renewal automation and responsibility. Do not infer coverage from the product name alone.
Bring a verified checklist to GARMTECH
GARMTECH publishes separate pages for domains, hosting, and SSL certificates. Use them to identify the current service options, then ask for written confirmation of the exact domain, DNS, application, migration, backup, and certificate scope needed for your project. Send the checklist through contacts.
Sources
- Google Search Central: managing multi-regional sites
- ICANN: registrant transfer FAQ
- ICANN: Transfer Policy
- NIC.LV: domain-name policy
- Google Search Central: changing hosting without URL changes
- ICANN: The Domain Name System
- MDN Web Docs: Transport Layer Security
- Let’s Encrypt: Challenge Types
- GARMTECH: Domains
- GARMTECH: Hosting
- GARMTECH: SSL certificates