Naming conventions look like a small detail until the environment grows. Then unclear names become a daily source of confusion: nobody knows which server is production, which VLAN belongs to which site, which backup job protects which system, or whether a cloud resource is safe to remove.
A good naming convention is not decoration. It is operational memory.
Originally discussed on LinkedIn: IT infrastructure naming convention post.
Why naming matters
Clear names help teams understand assets quickly. They support troubleshooting, change control, audits, monitoring, backup reviews and handover between staff or vendors.
Poor names create risk:
- production and test resources are confused
- duplicate names appear in different systems
- firewall rules become difficult to interpret
- backup jobs are hard to match to servers
- old cloud resources remain because nobody knows what they do
- support teams waste time asking basic identification questions
The best naming conventions are simple enough to follow consistently.
A practical naming structure
One example pattern is:
MY-KL-PROD-WEB-01
This can be read as:
MY: country or regionKL: locationPROD: environmentWEB: system role01: sequence number
This is only an example. The organisation should adapt the structure to its actual sites, systems and operational needs.
Physical servers and virtual machines
For servers and VMs, names should usually identify location, environment and role. Avoid names that are funny but unclear. A server called IRONMAN may be memorable today, but it does not tell a new administrator whether it is production, development, database, domain controller or web server.
Useful components may include:
- country or site
- environment such as PROD, TEST, DEV or DR
- role such as WEB, DB, APP, DC, FILE or BACKUP
- sequence number
Cloud resources
Cloud naming needs discipline because resources are easy to create and forget. Use names that show environment, workload, owner or service role where appropriate.
For cloud resources, also consider tags or labels. Names alone may not carry every detail. Tags can record cost centre, owner, lifecycle, project, compliance requirement and support contact.
Firewalls, switches and VLANs
Network naming should make physical and logical design easier to understand.
Examples:
- firewalls may include site and HA role
- switches may include site, floor, rack or function
- VLAN names should describe purpose, not only a number
- wireless SSIDs should be documented against intended user groups
A VLAN named VLAN20 tells you almost nothing. A documented VLAN such as MY-KL-USERS or MY-KL-GUEST is easier to understand.
Storage and backup jobs
Storage names should connect to the workload they support. Backup jobs should clearly identify what they protect.
Avoid backup job names like Backup1 or NewJob. When an incident happens, unclear backup names slow recovery.
Useful backup naming components include:
- protected system
- backup type
- schedule
- retention group
- location or repository
Service accounts
Service accounts should be named carefully and documented. They are often long-lived and easy to overlook.
Good practice includes:
- use a clear service-account prefix
- identify the application or service
- avoid using personal user accounts for services
- document owner and purpose
- review permissions periodically
Environment identifiers
Environment identifiers prevent dangerous confusion. Common examples include:
PRODfor productionTESTfor testDEVfor developmentUATfor user acceptance testingDRfor disaster recovery
Keep the abbreviations consistent. Do not use PRD, PROD and LIVE interchangeably unless there is a documented reason.
Governance and documentation
A naming convention only works when it is documented and reviewed. The document does not need to be huge. It should explain:
- approved abbreviations
- required name components
- examples by asset type
- exceptions
- who approves changes
- where names are recorded
New systems, cloud accounts and network changes should follow the convention from the start.
Practical checklist
- Choose a simple format that people can apply consistently.
- Include environment, location and role where useful.
- Avoid jokes, personal names and ambiguous abbreviations.
- Document examples for servers, network devices, VLANs, backups and service accounts.
- Use cloud tags or labels where names alone are not enough.
- Review old names during migration or cleanup projects.
- Make naming part of change control and onboarding.
Final takeaway
Good names reduce operational friction. They help the next person understand the environment faster, especially during troubleshooting, audits and recovery work.
Need practical technology or training support?
Tell us what you are trying to improve and we can suggest a realistic next step.
Contact IOT SOLUTIONS