Define and document "upsizing" plan for reference architectures

We should add to the reference architecture documentation to help guide customers as they grow from one architecture to the next one smoothly and confidently.

Problem to solve

Customers frequently start want to start small and scale-up their GitLab architecture as adoption grows. Currently, the reference architectures provide great starting-points for these customers, but they often worry about the complexity of migrating from one to another. Adding migration steps in each reference architecture to the next reference architecture "up" would reassure customers of the complexity and time involved.

Proposed solution

As an MVC:

Adding a section at the bottom of each reference architecture simply listing the tasks that would need to be completed before adopting the next architecture.

eg. for the 1,000 user to 2,000 migration:

• Put GitLab instance into Maintenance Mode
• Backup the GitLab instance (https://docs.gitlab.com/ee/raketasks/backup_restore.html#back-up-gitlab)
• Restore the DB into the newly provisioned PostgreSQL node
• Reconfigure gitlab.rb file
• etc.

As a shoot-for-the-moon goal:

Add a new page between each reference architecture detailing a full step-by-step guide to do the migration, the expected time involved, downtime required (if any) and rollback (/downgrade) steps in the event of an issue.