Jeff Freund has written an excellent article posted on CMSWatch that discusses the problems you may encounter in a content management system as the amount of content it stores grows. A quote:

The easiest way to understand interface scalability is to think through a simple question about your content management system: what happens to my job and the job of the editors and authors when the amount of content in the system increases two-fold? How about five-fold, or ten-fold, or fifty-fold? It?s a question not many think to ask before making a CMS purchase, but it?s a revealing one. Many interfaces work very well with small amounts of content, but begin to break down when the amount of content in the system increases.

The concept of interface scalability is especially critical in content management systems where web browser-based screens predominate.

…

Interface bottlenecks typically result in creeping inefficiencies in editorial processes. Maybe it takes too long to find content because, while the system response time is fine, there?s simply too much stuff to wade through. Perhaps some operations you would like to make in bulk can only be conducted one at a time. Or maybe there isn?t an easy way to see who is working on what, so sorting out the week?s responsibilities takes editors several rounds of the kind of off-system emails and face-to-face meetings that the CMS was meant to obviate in the first place.

Our team at work has encountered many of these problems in working with CMS’s. The biggest challenge I have encountered around scale is not being able to modify the properties of an arbitrarily selected group of pages and/or content. While it sounds like an obvious function it is easy to miss it unless you’ve had some experience and/or good advice.

When you are evaluating the functions of a CMS, ask yourself how easy it would be to do the same type of operation to 1000 pages. What looks like a great interface for a single page may be unworkable for a 1000.

Ultimately, I think that systems that take have a content repository model (content can be disassociated from a page but still exist in the repository) will scale better than those that use a page-centric model (where content is tied to the page in which it is created on the site). In my experiece, page-centric system have a built in bias of editing single pages which leads to rather anemic features for multi-page operations.