Replacing a custom-developed CMS tool with SharePoint?

Question

I need to develop/create sharepoint portal site to replace a custom-developed asp.net CMS tool. This custom CMS tool is a classic content management tool that content authors create/edit rich-text contents, dynamic-hierarchical menus, and associate the content items with the menus. (Some detail: there are 5 level hierarchy on the menus, and content items can only be associated to the leaf nodes. And on the content pages there are tabs, in each tab a different content is displayed)

I need some ideas to enlighten me, how i should structure my sharepoint-site to replace this custom CMS system. Here is the question;

USING ONLY BUILT-IN SHAREPOINT

If i would go only the built-in sharepoint, I must structure all the (at-least four level menus) hierarchy by using site hierarchy that means content authors should use built-in Create Site feature to create any new menu item, and they should use Create Page to have a new content item. In this page, they should create rich-text content and should maintain the same feel&look on pages.

As you see, with only using built-in features this will not be effective because, everything is up to content authors. And the UI is sharepoin admin pages, which is not pretty user-friendly for content authors. In the best case, content authors dont need to do so much SharePoint work. Instead, they sould have such UI pages to easily create menu items, rich-text(html) items and associate the menu items with contents.

So how should i go? What is the best-practice in SharePoint for this kind of requirements. I can say to myself that this project won't be only built-in SharePoint. But how should i have my structure and development effort. Should i have the rich-text contents and menu items in some SharePoint lists, instead of SharePoint pages? And develop some custom application page to display the content in an appropriate manner?

PS: I have sharepoint development experience, so donot hesitate to give ideas containing custom web-part development, page-development etc.

Thanks.

Answer 1

Follow the website structure with site collections and sites depending on the security levels you require.

Work out what needs to be a managed path and what needs to be a site.

Look for the closest OOTB webpart for functionality if not look on codeplex most already exist.

Design your security groups with the site structure in mind, and think about a deployment tool that can be used to add new users / sub-sites easily.

When you have such a general requirement as you have stated it is hard to give exact answers, but altering an existing site needn't be complex, make a sitemap up, and design your site/site collection structure to match, watch for security inheritance, list inheritance etc, all this will also help you determine if you want to go down sandbox or farm route etc.

For menus create a webpart that reads from a list and make a webpart to edit this list, you could even use taxonomy for this.

For news you can use the blog site etc, almost everything you will require is out of the box somewhere, so just make an inventory and match it up to current functionality.

Overall: Make a complete inventory of the current site and match it to sharepoints structure and existing templates/web parts/functionality.