UC Berkeley Telecom Catalog instance does it in a similar way as expressed by Allen.  Note:  We have another instance which has a different process.

1. we have 3 instances:  dev, test, prod
2. Run pre-clone ATFs in dev and test
3. clone dev and test at the same time.  Do post-clone activities
4. run post-clone ATFs in dev and test
5. upgrade dev
6. in dev, do skip/revert/merges (some of which go into an update set)
7. in dev, run post-upgrade ATFs
8. in dev, validate system, post-upgrade
9. in dev, export skip/revert decisions, close update set
10. upgrade test
11. in test, apply dev skip/revert decisions
12. in test, apply post-upgrade update set
13. in test, handle any extra skip/reverts
14. in test, run post-upgrade ATFs
15. in test, validate system
16. in test, export skip/revert decisions
17. upgrade prod
18. in prod, apply test skip/revert decisions
19. in prod, apply post-upgrade update set
20. in prod, handle any extra skip/reverts
21. in prod, non-invasive smoke-test to validate system

If you have any questions, please don't hesitate to ask.

Thanks,

Terri

---

Terri Kouba, ESM Service Manager
University of California, Berkeley
Berkeley Information Technology | Enterprise Service Management
Email: kouba@berkeley.edu
We champion diversity. We act with integrity. We deliver. We innovate.