Component and service documentation Requirement for platform migration [closed]

Question

I have a sudden need to comprehensively document a moderately complex platform, and break it down into service and application components, and describe how these services can be migrated and are provided into a new platform which is cloud based.

Obviously in both a desire for brevity, and a desire to comply with the rules of the site, I am not looking to get into discussion about benefits and types of documentation, just to capture the basic list of "facts" that manage a generic application stack.

My initial off-the-top-of-my-head list is as follows.

Support Services
Ticketing
Alerting
Escalation

Documentation
Build documentation
Service documentation
End-user documentation

Security
Configuration Compliance
Package and update monitoring
Vulnerability scanning

Backup & Recovery
OS Level
Application Data

Server Management
Bare metal Deployment
Configuration management
Upgrade & Package mngt

Shared Services
User Authentication
Internal DNS & DHCP
External DNS

Monitoring
OS level metrics
Service level metrics
External URL monitoring

Reporting
Web Analytics
Availability Reports
OS level statistics

If there is anything missing, I would be keen to identify it.

ps I would also be interested in excel or google docs templates to track these items.

Answer 1

Your list of items to document is relatively complete.

For format, my first suggestion is to make it match the other documentation in your company (if you use Wikis, wiki it. If you use SharePoint, put it in SharePoint, etc.) -- You want to make sure people will actually read (and update) the documentation.
Similarly if you have a specific document format at your company use that. Otherwise my suggestion is to break each practice area into a separate document (Backup & Restore ; Provisioning & Deployment ; Monitoring & Metrics ; etc...) -- Make them logical units that can have a specific person responsible for them.

(Note that "Security" is a special case -- Implementing and maintaining secure systems should be covered in EVERY OTHER BOOK, and the Security book should just be the general company security policies that drive that implementation. This tends to be a cleaner/more sensible setup than having everyone fight over the security book because they need to look something up.)