Moving Large MOSS 2007 Sites and Content

 

[Note : This post is part of  my main blog on “SharePoint 2010 Migration”]

What is Moving Large Sites?

• If your Site Collection is over 200GB and hence the underplaying dedicated content database should be over 200GB exceeding the Microsoft recommended Max size for Content Database.

• The Content and Site segregation effort is to move out such data to separate Site Collections and in to a separate content database or an existing smaller database if you prefer, there by reducing the over all size of your larger content database.

• The your site collection could have several Lists and Libraries with over 1000 items and over 2000 items per list or library and they might be continuing to grow.

• The site collection may also has several Document libraries that are over several GB in sizes and may or may not fall under the above said categories of over 100o items.

• You will need to analyze to understand where things are growing.  I will cover the steps for this in the Analysis section below.

• Hence your design for moving such content requires a very flexible approach to pick and choose each given list, library and may be an entire site (SPWeb) to be moved to given new site collection or an existing site collection.

• I call this moving selective content to separate sites as “Segregation”.

Design Considerations

• You want to ensure that the segregated content in the new site collection carries all content, date and time stamps, metadata, pages and applicable settings, security information.
• You want to your segregation approach to be able to handle each given scenario such as move a site, move a list or library.

Available tools and options

MOSS 2007 has following two options when it comes to moving/copying content:

• Content Migration APIs (PRIME): More granular support (Up to item level), full fidelity.
• STSADM export/import operations: Uses the above API but less granular (Web Level Only), less fidelity.
• Content Deployment UI interface via the Central Admin interface, does not apply here as it is meant for deploying to a target site.

Design Approach

• Based on the need to support the individual items consider implementing a data file so that you can feed the data file to your process.
• The configuration data file should mention a give list , library or a site as Source Object to be moved.

• For each such Source Object, a Target should be mentioned.

  • The target can be a  new or an existing site collection,

  • For existing site collection, the location within the site collection as where to be moved.

  • For a new site collection , the name, URL, type of site template will need to be determined.

• For entire segregation process a default set of parameters should be motioned such as minimum version to be migrated such as last 10 versions. And Only on demand this parameter should able to be overridden for any given Source Object to be migrated.

• The segregation export and import should support entire set of metadata, version history, file status as is (if checked out if possible) , user permissions configuration.

The segregation should also support consistent, as-is migration of data from source to target.

Design Constraints and Decisions

Implementation Approach:

• For the purpose of providing flexible model, I choose Content Migration API.
  • Following are some good references:
    • http://www.sharepointnutsandbolts.com/2007/10/stsadm-export-content-deployment.html
    • http://blogs.technet.com/b/stefan_gossner/archive/2007/08/30/deep-dive-into-the-sharepoint-content-deployment-and-migration-api-part-1.aspx
    • http://spdeploymentwizard.codeplex.com/

 

Site Collection Creation and re-parenting see me other blog.

Locking the Exporting Site Collection see my other blog.

Export and Import API call specifics see my other blog.

Drawbacks of current List Export and Import Content Migration APIs see my other blog.

Hot to programmatically copy Web Level, List level and List Item Level Security Information see my other blog.

Technorati Tags: Moving/Copying Sharepoint Content

SharePoint 2010 Migration

 

What am I blogging about?

Back in 2007 I did the MOSS 2007 migration with great success, that this year I am back to perform SharePoint 2010 migration, with several Web Applications worth TBs of data with several customizations. I want to use this blog as main page to start capturing major steps and tit-bits of  my findings.  I will try to capture the details in an order so that you can use it as a guidance for your migration.

Disclaimer

Whatever I can post here are general information relating to the topic and are provided as general motive of sharing with the community.

Steps in the order

Blow are major steps as I approach and for each I will be including sub activities and detailed blog for each such topic.

1. Why to migrate to SPS 2010?
   • Among other product significant improvements, MOSS 2007 Mainstream support to end soon 4/10/2012.
2. Set up your development environments.
   • If you have very simple sites with no customizations, or if you already have your development/test environment then you are covered.
   • Otherwise your step step should be getting your development environments setup for both MOSS 2007 and SPS 2010 platforms.
3. Simulate your web application(s).
   • If  your web application are running on SSL here is how to implement SSL in development, see my other blog here.
4. Perform Analysis
   • You want to know your current environment, your web applications/portals/sites, sizes, databases, customizations.
   • Get sense of what if you were to migrate by running the stsadm preupgradechecker, SPS 2010 run Test-SPContentDatabase power shell command.
   • What is pre Upgrade Checker report and what it is not, see my other blog.
5. Preparation for Migration
   • If your content databases are larger than 200GB or approaching this size, you may want to think about breaking up Large Sites and or moving site collections to other or new content databases. (Here is my new post on Moving Large MOSS 2007 Sites and Content )
   • How to get your Web Size, list and library size?
6. Migration Design (Coming soon…)
7. Migration Implementation(Coming soon…)
8. Migration Testing(Coming later…)
9. Deployment(Coming later…)

Technorati Tags: SharePoint 2010 Migration,Sharepoint 2010 Upgrade

What is pre Upgrade Checker report and what it is not

 

[This post is part of my main blog post on SharePoint 2010.]

The Pre Upgrade report captures three different levels of information:

• Farm level information
  • OS Level
  • SharePoint Farm topology
• Application level configurations
• Content level State information

The context of Pre Upgrade report run is under the context of what if we were to perform an In place upgrade in the same farm MOSS 2007. 

If your MOSS 2007 farm OS is Win 2003 or 32bit,  you will see OSPrerequiste is failed. Since you are not going to be using the same farm and will not be doing the in-place upgrade this is attribute status is not applicable.

More to come…

Developing Sandboxed Solution in SPS 2010 Tips:

 

Here I will be collecting all the relevant information that would help us deal with development and deployment of  Sandboxed Solution for SharePoint 2010.

Design

• Ensure the API/Class you intent use are available in Sandboxed solutions supported framework: Check the specific API/Class in MSDN. Note that MSDN has specific flag to denote if the specific API is available in Sandboxed solution.

                   

 

 

Development

• In order to ensure proper development copy the SharePoint dll locally only during development, later take it out to deploy….

Deployment

• More to come…

Implementing SSL Certificate for IIS Sites in Windows 2003 Server for Development Purpose

 

Scenario

You have Windows 2003 server (x86 or x64) with IIS 6.0, this is your development server, you have to test several of your web sites with SSL and all of these web sites happen to be on same domain name such  as site1.mydomain.com, site2.mydomain.com, site3.mydomain.com …..

Disclaimer

I am not a Security/Certificate expert, but in this below blog I want to share my steps that have worked very well for the purpose of development to implement SSL certificates using SelfCert tool.

What can you do?

Instead of assigning individual certificates you can choose to implement wildcard certificates. such as getting certificate created for *.mydomain.com.

You can use SelfCert utility which is part of IIS 6.0  resource Kit tools.

You can use SSL Diagnostic utility which is part of IIS  6.0 resource Kit to finally validate the certificate assignments to your site.

How to implement wildcard Self Certificate in Windows 2003 server with IIS 6.0?

High level steps:

1. In IIS create all your web sites (Site1,site2,site3….)
2. Use Selfssl to create wildcard certificate and assign the certificate to given existing web site on your IIS.
3. Then export the certificate along with private key to .pfx file.
4. From your local machine certificate store, import the certificate in to Trusted Root Certificate Authority.
5. From IIS, for each of your Site, assign your newly imported wildcard certificate.
6. From command prompt assign securebindings for each of your site.
7. From your client Browser, add your wildcard domain name as trusted site.

 

Step 1: Create IIS Sites

Create your IIS Sites from the IIS first. You don’t have to assign host headers at this time. We will cover the host headers later.

Step 2: Create Certificate

First download and install the IIS Resource Kit.  The utilities you choose will be installed at <SystemDrive>:\Program files[(x86)]\IIS Resources\

As first step lets first create a wildcard certificate for your domain name “*.mydomain.com” for example. 

We will use the selfssl tool to create a wildcard certificate against any one of the IIS site. (We will apply the certificate to all sites later). Go to command prompt and navigate to the folder where the Selfssl utility is stored. You can try SelfSsl /? to see all the options available.  Follow below syntax:

<SystemDrive>:\Program files[(x86)]\IIS Resources\>selfssl.exe /N:CN=*.<mydomain.com> /S:<IISSiteID>

Where substitute <mydomain.com> with your common domain  name, and for <IISSiteID> substitute IIS Site ID as displayed in the IIS manager Identifier column. (Default site is always 1, user created sites will have large number)

Above step creates an wildcard  certificate against your given site and stores the certificate under the Local Computer >Personal store.

Lets check this out:

From the command prompt run MMC. Add snap-in for Certificates, and choose My Computer.

 

Now navigate to the Console Root>Certificates (Local Computer)>Personal>Certificates. Here you should find your newly created wild card certificate along with the Machine Certificate and any other personal certificates.

 

Step 3: Export the certificate

Now lets export this certificate  out along with the private key, so that in the next step we can import in to the Trusted Root Certificate.

You can export this certificate from two different spots. Either from the Certificate management console that we opened in the above step to verify or from the IIS manager over the IIS site where we had created the wildcard certificate against.

From either spot you can launch the Certificate Export wizard.

From Certificate management console, you can choose your wild card certificate, right click, All Tasks, Export.

Or from IIS, right click over your site that you have used for selfcert command, Directory Security,  Click on Server Certificate and choose “Export the current certificate to a .pfx file.

Choose a file name and local folder where you want to exported certificate to be saved.  In the next step, provide password to protect the Certificate as you are also exporting the Private Key.

Step 4: Import certificate to Trusted Root Certificate Authority.

Now switch back to the Certificates management console. Navigate to the node “Trusted Root Certification Authorities>Certificates”.

From the Certificates node, right click and choose to import certificate.

Now choose the above saved certificate file to import, enter the password entered above to encrypt the certificate file.

Next choose to import the certificate as below.

Next confirm a successful import.

Step 5: Assign wildcard certificate from IIS

Now switch to IIS MMC. For each of your IIS sites, assign the newly acquired selfcert generated certificate. Leave the SSL port as is and the default port as is. The sites may be in stopped state and that is fine at this stage, since all of the sites are using the same default port 80.

Step 6: Assign securebindings.

Prerequisite for this step is that you have already installed the IIS Administrative Scripts located as below:   (If not install from your Control Panel>Add Remove Windows Components>Choose IIS to reinstall the AdminScripts >

Now go to IIS MMC, note Identifier for each of your Sites that will require the new certificates to be assigned.

Go to command prompt and change directory to the above highlighted AdminScripts folder.

Enter following command for each of the IIS sites that you want the certificate is assigned.

cscript.exe adsutil.vbs set /w3svc/<site identifier>/SecureBindings ":443:<host header>"

where host header is the host header for the Web site, for example, site1.mydomain.com.

After above steps are completed, go back to IIS MMC and start each of your sites.

Step 7: Add to Trusted Sites

From your development server browser, add your wildcard domain name as trusted site. (*.mydomain.com)

 

Validation

From the installation of IIS Resource kit you will also get SSL Diagnostic tool installed.

Run the SSL Diagnostics tool. The tool will check SSL certificate for each of the IIS sites and provide report as below.

In the above screen cap, I have masked the domain names I had used, but you should expect to see your respective wild card domain name.

Next browse to each of your IIS Sites from the Browse and you should be able to see your site without any certificate warning.

Hope these steps will simplify your SSL implementation for the purpose of development

Things to consider beyond just SSL

• Simulate SSL per site in your development environment.
• Address your browse warning for mixed content if present.
• Will update further if anything comes across my attention.

Start and Stop Batch scripts for SPS 2010 Developer Workstation

 

Overview

There is enough resources to setting up your Windows 7 Developer workstation for running SPS 2010. On an occasion we may not always run the SharePoint 2010 and the SQL Server on our Win 7 workstation or our lap tops all the time. Here I have been using Batch scripts to on demand Start and Stop quickly SPS 2010 and SQL Server services.

Place the below script in a batch file and run as administrator to start or stop your  SharePoint and SQL Services. Not the order  or start and stop matters so pay attention.

Make sure you set each of the services to start manually in your Services console so that its the script that controls the service activation.

Below in both the scripts make sure to substitute for your <YourSQLServerInstance> name.

Start Script

net start <YourSQLServerInstance>
net start sptracev4
net start spadminv4
net start w3svc
net start iisadmin
net start sptimerv4
net start SPUserCodeV4
net start SPSearch4
net start OSearch14

Stop Script

net stop W3SVC
net stop IISADMIN
net stop SPSearch4
net stop OSearch14
net stop SPTimerV4
net stop SPUserCodeV4
net stop spadminv4
net stop sptracev4
net stop <YourSQLServerInstance>

 

Happy Sharepointing….

Implementing Multiple Documents Approval Workflow in SharePoint 2007

 

Overview

OOTB SharePoint 2007 has support for running workflows at an Item level but not as applying workflow at group of items. This will be supported in SharePoint 2010 with Documents Set.

recently I had opportunity to design and implement one such workflow where approvals for multiple documents was required. Below I am sharing thoughts and approach to the architecture and design approach and various design element.

Workflow Architecture

• Below is the high level architecture of the Multiple Documents Approval Workflow implementation.
• I have discussed the logical architecture implementation approach.
• First lets review some of the common necessary workflow components.

Necessary Workflow Components

1. Generally complex document workflows may need to support  both serial and parallel approvals.
2. Front end screen should support end user to interact with the workflow components.
3. Behind the End User Screen, there will be SharePoint lists and libraries assets.
4. These lists and library assets will facilitate capturing following data:
1. The Workflow Metadata-Forms Library
2. The Workflow Tasks- Tasks List
3. The Workflow History- Custom List
4. The Approval documents- Document library.
5. The custom workflow will be deployed to the Custom Workflow Library.
6. End user will interact with the workflow with Submission and Approval forms.

Key Design Concepts for the Workflow that would facilitate multiple documents approval.

1. The key to the design is that a Workflow running on the Custom list will allow to capture the Business Specific metadata.
2. The workflow running at this custom list will operate at the each approval item level.
3. The workflow process should allow both Serial and Parallel Approval.
4. The Workflow forms should allow for the End Users to upload multiple approval documents at each workflow level.
5. This multiple document upload should then trigger a sequence of events by the workflow.
6. These should be to generate a new unique workflow number for the workflow event.
7. Then create a sub folder under the "Approval documents Library" with folder name as Approval  Workflow Number.
8. Then upload all the user documents to this sub folder, check in the documents with minor version 0.1.
9. Further for each approver review, each documents should be presented to the end user with document version and check in/check out status.
10. For each document the reviewer should be able to check out and update and check in back the document with the check in comments.
11. The checked in comments will be stored at the document library level.
12. Each approval workflow level Approval/Revise/Reject comments will be maintained at the workflow level.
13. After each check in check out a minor version should be incremented.
14. If you have phases in the workflow say after each major phase a Major version to be incremented.
15. After each user submission, necessary confirmation and next step notification emails will be generated for appropriate workflow participant.

 

1. Process Flow
1. Originator starts by clicking on the "Submit New for Approval" button from the "Workflow Management" section.
2. System should confirm user intention to actually initiate a new workflow. (Yes/No)
3. System to initiate a new workflow process (1).
4. System to generate a new Workflow Number (2)
   1. Sequential number or some code form such as code for Your Workflow  YW-2010-000001, YW-2010-000002, needs to be determined at implementation time.
5. System to create a new folder by the name of Workflow number.
6. System to present end user with Submission form. (3)
7. End user to enter workflow approval data and upload multiple approval documents. (4)
8. Each uploaded documents will be actually uploaded under the above created subfolder by the workflow number under the Approval Documents library.
9. End user to submit the workflow. (5)
10. System to capture workflow meta data and update the Approval Workflow custom list. (2)
11. System to generate appropriate notification emails.
12. System to create new task for the next approver.
13. Next approver to either open the received notification email, and click on a email link to respond to the pending task, or from the Workflow Management screen, look up the pending task from the "My Tasks" and click on the link to open the task.
14. System to present Approver with new Approval Form (6)
15. Approver could open any approval documents and review.
16. If the approver wants to edit the document then approver must first check out the document, make their edit, save the document and check the document back in. (7)
17. Workflow to advance further for each workflow defined steps and process the remaining steps.
18. Upon workflow completion, the state for the documents need to be determined at the implementation time based on weather the workflow was approved or rejected.

End User Views

1. My Tasks
   1. This view to list all the active tasks for the current user.
   2. End user should be able to act on the pending task by clicking on the task.
   3. This list is sortable/filterable

1. Specific list of columns and the default view will be determined at the implementation.

1. Active Workflows
   1. This view to present list of all the active approval workflows
   2. This list is sortable/filterable

1. Specific list of columns and the default view will be determined at the implementation.

1. Approval Documents
   1. This view to present end user with all the approval documents that belong to the active Approval Workflows.
   2. End user could directly open the documents for review purpose.
   3. End user could directly check out, open the documents for edit purpose.
   4. End user could directly check in, the documents with the per document review comments.
   5. This list is sortable/filterable

1. Specific list of columns will be determined at the implementation.

1. Workflow Management
   1. This control to present end user with button to initiate a new workflow
   2. This control to also present end user with workflow search controls.
   3. Search results will be displayed on a separate search page.

1. Completed Workflows
1. This view to present end user with all the approved documents .
2. These documents are only for read only.
3. End user will not be able to edit/delete or make any changes.
4. This list is sortable/filterable

1. Specific list of columns will be determined at the implementation.

Implementation Options

1. Workflow Technology options
   1. Out of the Box SharePoint Workflows
      1. Approval
      2. Feedback
      3. Signature Collection
      4. Disposition

1. SharePoint Designer Workflows
   1. Wizard Driven Designer.
   2. Very good Conditional flow builder.
   3. Limited auto forms generator.
   4. Deploy to a single list/library.

1. VS.NET developed custom workflow
   1. Custom Coded workflow process.
   2. Custom workflow provides broader opportunities for workflow logic and future capabilities implementation.
   3. No UI Support (use either ASP.NET or InfoPath form).
   4. Can be deployed to any server any site any list.

1. Forms Options
   1. ASP.NET
      1. Custom ASP.NET pages can be developed to provide Forms functionality.
      2. These custom ASP.NET pages will need to be a SharePoint master page inherited pages and should follow SharePoint development standard.
      3. Will be complex to develop.

1. InfoPath Forms and SharePoint Forms server
   1. Custom InfoPath Forms can be developed to provide adequate End user Forms experience.
   2. InfoPath forms technology is meant for this Forms functionality.
   3. To add to the InfoPath strong feature, SharePoint brings in the Forms server technology.
   4. The Forms server is capable of delivering the InfoPath forms via the browse interface, meaning end user do not need InfoPath rich client to interact with Forms.
   5. InfoPath provides rapid development experience.
   6. The minimal configuration of the Forms Services provides excellent mechanism for delivering the Forms to the end user browser in a workflow process.

1. Landing Page Web Parts
   1. For each of the Workflow Management page views, Out of the box web parts can be utilized and customized.
      1. My Tasks
         1. This will be a filtered List view web part on the Workflow Tasks list.
         2. This Web part will be filtered for current user by connecting to a Current User Filter Web part
      1. Active Workflows
         1. This will be a filtered List view web part on the Workflow Tasks list.
         2. List View will be filtered for where status is not "Completed".
      1. Approval Documents
         1. This will be a filtered List view web part on the Approal Documents library.
         2. List View will be filtered for where the documents are Approved.
      1. Workflow Management
         1. This will be a Content Editor Web Part with custom HTML code.
         2. The HTML code will facilitate the end user confirmation via the JavaScript and further upon confirmation, initiation of the workflow.
      1. Approved Documents
         1. This will be a filtered List view web part on the Approval Workflow custom list.
         1. List View will be filtered for where status is "Completed".

1. Document Management
   1. SharePoint provides Document management functions Out of the Box
      1. Check in Check out
      2. Versioning (Minor, Major)
      3. Document Approval

1. Detailed Implementation Options and Comparisons
   1. Out of the Box SharePoint Workflows
      1. Design
         1. Simply Configure each workflow for a given list/library.

1. UI
   1. OOTB submission and approval pages

1. Deployment
   1. SharePoint Feature Driven, simply activate appropriate workflow features. By default all workflows are activated.

1. Extensibility
   1. Not available

1. End User Experience
   1. Relevant for the limited functionality

1. SharePoint Designer 2007 designed workflows
   1. Design
      1. Declarative Workflow Design experience through wizard
      2. Simple Initiation form auto generation for submitter.
      3. Simple Task form auto generation for approver.
      4. All SharePoint designer workflows are flow chart type and do not support State type machine workflows.
      5. Wizard Driven Experience

 

1. Deployment
1. SPD workflows are always deployed to a single list/library.
2. There is no packing and deployment option.
3. There is coding involved.
4. All the auto generated workflow definition files are deployed to SharePoint hidden library
5. However there are hacks to pick these files and re design or make use of these files in VS.net as new workflow (but that is out of scope for this discussion)
2. Extensibility
1. Use SPD to open the site "Live" and open the workflow.
2. Modification could potentially break the active workflow instances.
3. End User Experience
1. Submitter to see the above initiator screen, but there is no way to provision the document attachments or reference other related documents.
2. With alternative approaches, at the least we could accommodate a free text field where the submitter lists all the approval related documents. Or a document library with each new folder with workflow number where the documents are uploaded.
3. More disconnected experience
4. Version Management
1. SharePoint will maintain all the workflow deployed versions.

1. VS.NET developed custom workflow
1. Workflow Development
   1. Customizable with design canvas with predefined controls.
1. Provides great depth of freedom to implement business logic.
2. Could implement support for Multiple Documents approval
3. Can implement both flowchart type workflows with Parallel and Serial workflows and a state machine based workflows.
4. Complex to implement
5. Time consuming to develop
6. No integrated UI development
7. But can integrate with InfoPath or ASP.net separately (Covered below
2. UI choices
1. InfoPath
1. Design using InfoPath Office Application, rapid development.
2. Deploy with Browser enablement. Easier to enable.
3. Rich end user experience
4. Simple integration with VS.net workflow
5. Complex to perform data integration with VS.net workflow (Time consuming)
2. ASP. Net
1. Alternative option.
2. More time to develop than InfoPath
3. Would choose if there was no Forms server and was only WSS (Comes with MOSS Enterprise license)
3. Deployment
   1. Entire workflow components can be packaged as a SharePoint Solution Framework.
   2. Can be deployed as intuitive SharePoint Feature
   3. Solution feature can be controlled by administrator
   4. Workflow can be developed and tested and deployed to each different servers
4. Extensibility
1. Custom tasks types can be developed to implement special or non OOTB functionalities (reference to multiple documents)
2. But it will be a complex task.
3. Workflow solution can be further updated and the Features can be further deployed by carefully evaluating the impact of deployment and retention of active workflow instances.
5. End User Experience
   1. More intuitive and richer experience due to advanced Forms entry, data presentation and submission experience.
   2. Easier workflow interaction with custom build Web part components.
   3. Advanced and more interactive reporting experience.

Design Constraints

1. Out of the Box Workflows
1. Comparison with OOTB workflows and requirements
2. Each OOTB workflow is one leg of our requirements
3. We cannot bind them one by one serially to achieve our designed flow
4. Not being able to update multiple documents.
5. SharePoint workflows are single document-centric processes
6. From a document library, you can choose document and then choose to kick of a workflow

1. No dynamic task assignment.
1. No task assignment based on availability.
2. Cannot check for Out Of Office from Exchange Serve
2. SharePoint Designer 2007 Workflows
1. The auto generated simple forms do not support any onscreen validation or conditional data input.
2. Every input is independent field.
3. Data validation logic cannot be enforced.
4. Only data
5. Multiple Document reference and document management functionality cannot be implemented. (may be very complex to implement)
3. Approval Document management has to be handled separately from the workflow process and directly from the Approval Documents library.
   1. Workflow process and the document review process managed directly from the library would go independently.
   2. This to provide more disconnected end experience.
4. SPD Workflows lack deployment functionality to more than one location.
1. One developed and deployed against a single list/library under say development server, we cannot take out just workflow process and deploy against a Production server.
2. There are other alternative approaches to mitigate this issue.
1. Once developed clean up the development test data.
2. Back up the site collection.
3. Deploy restore the site collection in production.
4. But this can happen only one time.
5. Thus modifications cannot be easily developed under development environment and deployed to production.
6. Only production workflow has to be directly modified for any future updates risking loosing /inadvertently affecting production data.
7. There are other hacking options, but would not recommend as there are chances of loosing/affect the production system.

Capacity planning

• Other items that needs to be addressed are the capacity planning and include your growth plan.
• Consider how many average documents per workflow.
• Give attention towards the know SharePoint guidance for over 2000 items per view.

Implementation Decisions

Then work through your Implementation decision strategy such as to implement which specific feature using possible technology options. You can prioritize each of these requirements. This should further help you to decide which option makes more sense on the larger scale.

Requirements Prioritization

Priority: High/Medium/Low

*Design Impact: In the order of function availability to low cost simple design to advanced end user experience with high cost of development. Any selection of choices selects corresponding type of technology choice across. Choices are among (OOTB, SPD, VS.net Custom Workflow)

Let the Business/Client/End user decide on the prioritization.

Hope this helps….