Migrating from Site Server to Commerce Server 2000

  • Article

 

Microsoft Corporation

December 2000

Summary: This article discusses how to migrate an e-commerce site developed with Microsoft Site Server 3.0 or Site Server 3.0 Commerce Edition (SSCE) to a site based on Microsoft Commerce Server 2000. The article includes a feature analysis of the two servers and gives details about planning, developing, and deploying a migration strategy. (31 printed pages)

Contents

Introduction
Planning the Migration
Developing
Deploying

Introduction

Migrating an e-commerce site developed with Microsoft® Site Server 3.0 or Site Server 3.0 Commerce Edition (SSCE) to a site based on Microsoft Commerce Server 2000 requires careful planning. You must first analyze how your site uses each Site Server feature before you can determine its migration path. Most SSCE features have corresponding features in Commerce Server, but some Site Server 3.0 features do not.

Although Site Server 3.0 and SSCE provide excellent deployment platforms, neither can take advantage of Microsoft Windows® 2000 technology, which includes advances in directory services, clustering, and administration. By using Commerce Server, you can leverage the advantages of Windows 2000 Server. These advantages include a comprehensive set of Web and Internet services that are compatible with the latest Web technologies, from simple site hosting to advanced Web applications and streaming media services.

Commerce Server also works with Internet Information Services (IIS) 5.0 to provide robust and powerful e-commerce services. IIS 5.0 provides your Web site with an interface for interacting with the authentication engine of Windows 2000. IIS also provides an interface to the networking protocol layer and the front end for servicing client requests. This seamless interface allows IIS to interact with Commerce Server as a collection of Active Server Pages (ASP), HTML, dynamic HTML, and other objects.

Active Directory

Instead of maintaining a separate membership directory as you did with your Site Server 3.0 or SSCE site, Commerce Server uses the Windows 2000 Active Directory™ directory service to provide membership services. Active Directory provides a hierarchical view, increased extensibility and scalability, and distributed security that large organizations require. When you use Active Directory, you don't have to implement and manage additional directory services, so you can save on administrative and hardware costs. Active Directory integration provides single sign-in per-user authentication, instead of tying security to a certain incoming Internet Protocol (IP) address and requiring users to log on again to provide their names.

You can scale Active Directory from a small installation with a few hundred objects to a very large installation with millions of objects. Active Directory also provides an extensible schema, which contains a definition for every object that can exist in a directory service.

Commerce Server Site Packager

Commerce Server includes a new deployment tool called Commerce Server Site Packager, which you use to package all of the contents of a Commerce Server site and install the same site on another Web server. Site Packager packages all the content, scripts, configuration information, and all other relevant data about a site into a binary file, which can then be transported to other servers for unpacking. This facilitates the installation of your site across an entire server farm. Site Packager can be run from a command line interface so you can easily incorporate it into scripts for building new servers.

Commerce Server Business Desk

Commerce Server Business Desk is a Web-based site management tool that hosts business management modules. You can use these modules to perform tasks, such as the following:

  • Make changes to a site, such as changing content, updating a catalog, or targeting new ads to users
  • Run reports to measure site productivity

Profiling System

SSCE used various types of records to store user attributes. Commerce Server provides a Profiling System that stores user attributes. You can use Active Directory and the Profiling System to create a virtual map of all attributes, thus making it appear to applications as though all user information is located in one physical database. Applications no longer have to ensure that a particular type of user data is sent to the correct database.

For example, an application requesting all user information receives all available data, including user name, password, address, telephone number, and e-mail address. In addition, the Profiling System can access the personalization store to retrieve a specific user's favorite color, stock symbols, or similar preferences.

It is important to note that the Profiling System does not create a new database. It manages the location of data stored in existing databases and provides an interface to the data for applications. The Profiling System also caches recently or frequently used records.

With Commerce Server, you can store user attributes by using either Active Directory or a Microsoft SQL Server database. If your site requires authorization and a security context for each user, you can store security attributes should be stored in Active Directory. If your site tracks personalization information for a user, that information can be stored in a SQL Server database. Commerce Server can locate and provide requested user data from either location.

If you require both authentication and personalization, the Profiling System can aggregate data between Active Directory and the SQL Server database. User authentication information, such as user name and password, can be stored in Active Directory, whereas the personalization attributes, such as favorite color and last time visited, are stored in a SQL Server database.

Before You Migrate

To migrate from Site Server to Commerce Server, you use the same methodology that you use to develop a new site:

  • Plan
  • Develop
  • Deploy

While you plan for migration, it is also a good time to plan a full upgrade of your site. During the planning phase, you should review requests for enhancements and analyze existing Web log data to determine what your customers need. Refer to the Commerce Server Getting Started Guide to plan site features that take advantage of the Commerce Server Profiling System, Product Catalog System, Targeting System, Business Analytics System, Business Process Pipelines, and the Commerce Server Data Warehouse.

When migrating your site from Site Server to Commerce Server, you can perform many activities in parallel, as shown in Figure 1.

Ee824045.migratingcode1(en-US,CS.10).gif

Figure 1. Migration timeline

Planning the Migration

As you plan how to migrate your site from one application to another, be sure to read this article thoroughly. The following table contains a list of questions you must answer as you plan your migration strategy.

Subject Question
Features What features of Site Server or SSCE do you use?
Risk management What risks are involved in upgrading your site to Commerce Server?

Do you expect to have periods of downtime? If not, what steps are you going to take to guarantee that your site continues to function?

What is your fallback plan?
Site upgrade Are you planning to take this opportunity to upgrade your site in other ways? For example, is it time to upgrade your servers to take advantage of the newest technologies?

Are you going to add hardware or reconfigure networks?
Timing What is your window of opportunity? How long will it take to migrate to Commerce Server?
Resources How much effort will it take to perform the migration?

How many people do you need to do the work?

Who are the people?
Knowledge transfer Who knows the most about your current site?

Are there additional people who need to have this information? If so, how are you going to transfer and preserve that knowledge?
Deployment How do you plan to deploy your new site?

Have you provided for each of the necessary environments (development, test, staging, and production)?

Have you planned how to implement operational procedures you need for the new site?
Testing Who will test the functionality and behavior of the site in the development and test environments?

The following table lists the types of items you must consider when planning your migration.

Item Consider
Data User profiles, receipts, orders, shopper records, product catalog, and so on.
Static site content HTML, GIFs, and so on.
Application logic ASP pages; pipeline, Microsoft Transaction Server (MTS), and middleware components.
Content deployment You can use Microsoft Application Center 2000 for content replication.
Content search Commerce Server provides product catalog searching capabilities, but not content searching; Windows 2000 Index Server provides intranet searching.
Platform software Commerce Server requires Windows 2000 Server and Microsoft SQL Server 7.0 or Microsoft SQL Server 2000.
Integration with existing third-party software Software for processing credit cards and orders, calculating taxes, and managing inventory, shipping, fulfillment, and other information that flows between your site and existing systems.

Your migration plan must contain at least the following elements:

  • Site architecture diagrams
  • Feature analysis
  • Supporting software
  • A plan for moving existing software and features forward
  • Acceptance tests for the migrated site
  • Operational plan for managing and operating the new site once it's in production

Before beginning your migration, see https://www.microsoft.com/siteserver for the latest system upgrades and installation instructions. Currently, you must do the following:

  • Upgrade your existing Site Server 3.0 or SSCE site to use Site Server Service Pack 4 (SP4).
  • Upgrade your SQL Server installation to the latest version compatible with Commerce Server (SQL Server 7.0 or SQL Server 2000).
  • Save your Web site usage logs in World Wide Web Consortium (W3C) format and archive them for import to the Commerce Server Business Analytics System.

Feature Analysis

As you begin to conduct a feature (or gap) analysis of your current site, with migration to the Commerce Server platform in mind, you should ask the following questions:

  • What is our current functionality with SSCE?
  • What features of SSCE are we using?
  • Which features does Commerce Server offer?
  • Which features does Commerce Server not offer?
  • What new features of Commerce Server should we use?

The following table shows how Site Server/SSCE features map to Commerce Server features.

Site Server/SSCE features Commerce Server 2000 features or related resources
Active Channel Multicaster/Active Channel Server (ACM/ACS) No equivalent functionality.
Ad Server Campaigns modules, which include added functionality. You can use the Ad Server Migration tool located in the Commerce Server 2000 software development kit (SDK) to migrate Ad Server from Site Server to Commerce Server. For more information, read about the Directory Migration Toolbox in "Developing Your Site" and "Migrating the Membership Directory" in Commerce Server 2000 Help.
Analysis–import Data Warehouse.
Analysis Report Writer Business Analytics System. Business Desk uses Microsoft Office Web tools to display reports. For details about how to create custom reports for existing data in the Data Warehouse, see Commerce Server 2000 Help.
Catalog Product Catalog System
Commerce Interchange Pipeline (CIP) Microsoft BizTalk™ Server 2000
Content Analyzer No equivalent functionality
Content Replication (deployment) Available from Application Center and from third parties. You can find the latest information about content replication software developed especially to work with Commerce Server at https://www.microsoft.com/commerceserver/.
Cross-sell functionality The Product Catalog System and Campaigns modules contain cross-sell functionality. However, there is no direct migration path.
Direct Mail Commerce Server Direct Mailer
Dynamic Directory Windows 2000 Server Internet Locator Service (ILS) (though it doesn't support dynamic replication).
Knowledge Manager Future release of Microsoft technology
Personalization & Membership Profiling System. Use the Membership Migration tool in the tools section of the Commerce Server 2000 SDK for this migration.
Order Processing Pipeline (OPP) Business Process Pipelines (pipeline components and Pipeline Editor)
Posting Acceptor Windows 2000 Web Distributed Authoring and Versioning (WebDAV)
Predictor Predictor resource, which includes added functionality
Promotions Promotions and campaigns
Publishing Wizard No equivalent functionality
Rules Expressions and ASP code
Search Commerce Server provides search capabilities on product catalog information. Windows 2000 Index Server provides search capabilities for intranet search. For more information about companies that provide capabilities for Internet browsing, see https://www.microsoft.com/commerceserver/.
Site Vocabulary Site terms (flat structure)
Tag Tool No equivalent functionality
Transactions Use the Transaction Migration tool found on the Commerce Server Resource Kit CD to migrate from Site Server to Commerce Server.

When you have finished your feature analysis, chosen which Commerce Server features to use, and decided which data items to migrate, answer the following questions:

  • What tools do we need to perform the migration?
  • What tools are available?
  • What modifications do we need to make to the code?
  • What testing do we have to do?

Migration Strategies and Scenarios

This section describes how to perform your migration in five phases. Before you begin, however, consider the following migration strategies:

  • Start with the Blank Solution Site provided by Commerce Server if you are migrating from SSCE to Commerce Server.
  • Design your catalog schema early in the development process.
  • Identify the advantages and disadvantages of using Windows 2000 Active Directory and SQL Server for your site. Based on performance and scale projections, begin building your profile storage system.
  • Focus on migrating to equivalent site functionality instead of trying to incorporate every new Commerce Server feature at the beginning. You can add other Commerce Server features later.
  • Upgrade SSCE to a Windows 2000 Server platform by using Site Server 3.0 Commerce Edition, SP4. This will make your migration easier because Commerce Server requires the use of Windows 2000 Server. Windows 2000 also provides a 30 percent to 100 percent performance improvement for SSCE sites.
  • Migrate your Microsoft SQL Server 6.5 or SQL Server 7.0 database to SQL Server 2000 to get clustered, full-text-search database support. The Commerce Server Product Catalog System uses the full-text-search capability built into SQL Server 2000. Although you can use SQL Server 7.0, the best practice is to use SQL Server 2000 because it fully supports clustering of the free-text indexes.

Plan to do your migration in the five phases described in this section.

Phase 1: Set up Commerce Server in your test environment

Your goals for a successful migration should include the following:

  • Minimal customer disruption
  • A fully tested destination platform with all functionality validated at production-level stress loads before it enters production
  • Sustained viability of the existing test platform used for pre-production testing and staging throughout the migration process

The migration technique described in this section accomplishes these goals. This technique assumes the following:

  • The existing SSCE site is in production close to 100 percent of the time.

  • You currently have a test/staging environment that can handle your current production load as a failover system, if necessary.

  • You have short-term access to additional hardware, network, and physical infrastructure to use during the migration. If you don't have access to the necessary additional hardware, you can substitute your test platform for the additional hardware.

    **Note   **Before you begin Phase 1, back up your entire system and thoroughly test your backup restoration procedure.

In Phase 1, you set up a new test/staging platform to continue supporting the existing SSCE-based production site. You then rebuild the old test platform by using Commerce Server to act as your pre-production environment. Figure 2 shows the state of the network during Phase 1.

Ee824045.migratingcode2(en-US,CS.10).gif

Figure 2. State of network during Phase 1

In Phase 1, you do the following:

  1. Build out your new production environment (N1) as a clone of your existing test environment (T1) and install SSCE. Your N1 environment will be made up of additional hardware that is not already in use in one of the existing site environments (development, test/staging, or production). Those environments should remain intact during this process.

    The Domain Name System (DNS) should continue to point at your existing production environment (P1); no changes have yet occurred. The following items are typical of the work that you need to do in this step (though this list might not include everything you need to do):

    • Build the hardware and network
    • Install Microsoft Windows NT® 4.0 Server
    • Install SSCE
    • Install Windows NT service packs
    • Install SSCE service packs
    • Using build-out scripts, add extended attributes to the Membership Directory
    • Configure Ad Server
    • Configure the Personalization & Membership feature
    • Configure the Web server or servers
    • Install site files
    • Install extensions to the site database
    • Configure the marketing system
    • Configure the analysis engine
    • Configure reports
    • Configure the transaction system
    • Verify that the site is fully functional in all respects

  2. Test and confirm that N1 is also an exact copy of T1.

    Confirm that all pages work as expected, including ads, promotions, cross sell, personalization, transactions, logging, and data storage.

  3. Make N1 your SSCE test site.

    • Update Content Replication System (CRS) jobs to post new code to the new test platform.
    • Notify your production staff of the change in test platforms.

  4. Rebuild the T1 environment as a Commerce Server site (Windows 2000, SQL Server 2000, Commerce Server, and so on). For instructions about how to do this, see the Commerce Server installation instructions located at https://support.microsoft.com/support/commerceserver/2000/install/default.asp

    • Format the hardware disk drives.
    • Follow product instructions for installing Windows 2000 Server on each server.
    • Configure the appropriate servers for Windows 2000 Active Directory.
    • Follow instructions for installing SQL Server 2000 on the appropriate servers
    • Follow instructions for installing Commerce Server on the appropriate servers.
    • Configure the appropriate servers for Windows 2000 ILS for caching support.

  5. Test Commerce Server in your T1 environment by testing it with the Blank site after you have unpacked it in Site Packager.

Phase 2: Migrate site code and content

In Phase 2, you deploy the migrated SSCE-based site to Commerce Server in the T1 environment. Figure 3 shows the state of the network during Phase 2.

Ee824045.migratingcode3(en-US,CS.10).gif

Figure 3. State of network during Phase 2

In Phase 2, you do the following:

  1. If you currently use personalization, you must migrate user data into a store that the Commerce Server Profiling System can use (SQL Server or Active Directory). You can use the Membership Migration tool (Directory Migration Toolbox) located in the Commerce Server 2000 SDK to help you accomplish this migration.

    • If you use a Windows NT 4.0 domain for authentication, see the document "Upgrading a Windows NT Domain" in Windows 2000 Server Help for instructions about upgrading the Windows NT 4.0 domain to Active Directory.
    • If your site contains personalization data not contained in the Windows NT 4.0 SAM or in the Membership Directory, you must move the data to another store. See Commerce Server 2000 Help for information about suitable stores and how to do this.
    • If you currently use a Lightweight Directory Access Protocol (LDAP) store that supports LDAP 3.0, the Commerce Server Profiling System can treat the existing store as a source for user information, but Commerce Server won't be able to authenticate users against the store. To authenticate users, you must supplement this store with another store (SQL Server or Active Directory) that Commerce Server can use for authentication. When you build a Commerce Server user profile, you must define a common join key that the ProfileService object can use to pull the appropriate attributes for a specified user from multiple stores.
    • If you currently use a SQL Server database to store personalization and authentication data, you might be able to use the existing store for the ProfileService object. For additional information about how to use an existing SQL Server–based user attribute store with Commerce Server, see "Adding a New Data Source" in Commerce Server 2000 Help.

  2. Migrate Ad Server system data, schedule, and tags. See the description of the Ad Server Migration tool later in this white paper for more information about how to do this.

  3. Convert content tags to Commerce Server expressions.

  4. Import historical logs into the Data Warehouse for the Analysis modules and Predictor resource to use. For instructions about how to do this, see "Importing Data into the Data Warehouse" in the "Running the Data Warehouse" section in Commerce Server 2000 Help.

  5. Migrate user transactions from the receipts table by using the Transaction Migration tool on the Commerce Server 2000 Resource Kit CD. If your site contains a significant number of receipts, you can modify the Transaction Migration tool to import only the last n number of transactions or transactions that occurred after a specified date.

  6. Migrate distribution lists by using the StaticExport.vbs script found on the Commerce Server 2000 Resource Kit CD.

  7. Re-create usage analysis reports to be used by the Data Warehouse and the Business Analytics System. For instructions about how to do this, see "Creating Custom Reports" in Commerce Server 2000 Help.

    Refer to the VCTurbo_CS2K folder on the Commerce Server 2000 Resource Kit CD for details about how to migrate existing SSCE code to run on Commerce Server 2000.

  8. Convert rule-builder logic into scripts that use expressions.

  9. Convert all scripts using the catalog system to use a Commerce Server catalog object.

  10. Implement the discount pipeline, as appropriate. For more information, see "About Content Selection Pipelines" in Commerce Server 2000 Help.

  11. Implement the advertising pipeline, as appropriate. For more information, see "About Content Selection Pipelines" in Commerce Server 2000 Help.

  12. Configure your system-monitoring tool to check for the new event and performance monitor values generated by Commerce Server, as appropriate.

  13. Create a backup package of your site.

  14. If you used Secure Sockets Layer (SSL) certificates, make sure that they are enabled on the new Commerce Server servers.

  15. Deploy and test any required third-party or custom components.

Phase 3: Move your new Commerce Server 2000 site into production

When your pre-production environment is fully functional, the next step is to move the Commerce Server site into production. Figure 4 shows the state of the network during Phase 3.

Ee824045.migratingcode4(en-US,CS.10).gif

Figure 4. State of network during Phase 3

In Phase 3, you do the following:

  1. Thoroughly test all site functionality in your pre-production (T1) environment.

    You can use the Web Application Stress (WAS) tool (located at https://homer.rte.microsoft.com) to test load against the new production site. A best practice is to perform a full transaction cost analysis (TCA) on the new site to verify that it will successfully support your current and projected loads.

  2. Rebuild your production test/staging (N1) environment as a Commerce Server test/staging site. (This becomes the temporary test facility for your Commerce Server site.)

  3. Unpack your new Commerce Server site in your new test/staging site (N1) environment.

  4. Confirm that directory migration components are in place and ready to begin migrating users when the new Commerce Server site begins functioning in your product environment.

  5. Import any additional production log files generated since Phase 2.

  6. Confirm that the content deployment technologies you have implemented are fully functional.

  7. Test all functionality on both Commerce Server sites (the production environment [N1] and the test environment [T1]).

  8. During a period of minimal usage, change the DNS and/or single Internet provider solution entry points to your new production (T1) Commerce Server environment.

  9. Enable directory migration components to support real-time and batch migration of users from the old Membership Directory (if appropriate).

  10. Test all functionality of your site from an external client to confirm full functionality.

    If the site fails, revert DNS and single IP to your SSCE P1 environment and determine what went wrong. When the problem has been identified and resolved, repeat Step 7 in this phase.

After 24 hours, if the site has remained fully functional, you can consider the site fully operational on the new Commerce Server–based platform.

Phase 4: Convert P1 to Commerce Server

Converting your existing production environment (P1) to Commerce Server is a relatively simple procedure, but it is most important to do this cleanly, with the least impact to site users.

There is a brief period during which you can move back to your Site Server site should a failure occur. The exact duration of this period depends greatly on your site's transaction volume. As a general rule, you can go back to your Site Server site within 24 hours if the Commerce Server site is failing for any reason.

**Caution   **If you revert to Site Server, there is no way to transfer the transactions performed on the Commerce Server site back into Site Server. The migration tools can't do bi-directional synchronization. This means that transactions recorded on the new Commerce Server site will be lost if you have to move back to your Site Server site.

In addition, the old SSCE-based site will not contain user information changed during the time the Commerce Server site was in production.

If you used the Membership Directory in conjunction with your old SSCE-based site, maintain at least a read-only instance of the Membership Directory that is capable of supporting the ongoing migration of users to the stores used by the Commerce Server site until user migration is complete.

Figure 5 shows the state of the network during Phase 4.

Ee824045.migratingcode5(en-US,CS.10).gif

Figure 5. State of network during Phase 4

Convert your old production environment (P1) to Commerce Server by doing the following:

  1. Rebuild the old production environment (P1) as a Commerce Server test/staging site. (This will then become your new test environment.)
  2. Unpack the latest copy of your site to the new test/staging environment (P1).
  3. Test all functionality of P1 to be sure it successfully functions as the test environment.

Phase 5: Decommission the N1 environment

When your Commerce Server production environment (P1) and test environment (T1) are fully functional, you can decommission the old test/staging site (N1), dismantle the hardware, and return the hardware to its previous use.

Fallback Plan

One important aspect of managing the risks of downtime or data loss to your site during migration is to prepare a fallback plan. A fallback plan describes the potential problems that might arise during the migration process, such as the following:

  • Hardware problems, including hardware configuration
  • Software problems, including platform software configuration
  • Performance
  • Interfaces with your existing corporate systems
  • Third-party software issues (for example, pipeline components that do not work)

You should back up the following data during and after the migration:

  • Product catalog
  • New accounts
  • Edited accounts
  • Transactions
  • Order history
  • Inventory information
  • Any site-specific, custom data

The following table describes mitigation strategies for a number of failure scenarios.

Failure Mitigation strategy
Errors or failure while setting up the new production site Perform thorough testing, including stress and load testing, before moving the new software into production. Consider "soft" testing or beta testing your site by pre-deploying it from the test environment to allow a limited number of users time to encounter any bugs before you move your new site into production.
Failure while moving your site from the test environment into the production environment Create a plan for immediately reverting to the old site. Test this scenario, if possible, by taking your production site offline, then bringing it back online. You can use your disaster recovery plan for this effort.
Failure of the new site in production Consider logging transactions of critical data items, such as orders and user profiles, in a format that the old site can readily re-import. This might require tool development, so you should consider it when estimating the development effort.

Developing

This section provides general development-related information and describes development best practices for migrating an SSCE site to Commerce Server. Be sure to see Commerce Server 2000 Help, the Commerce Server 2000 SDK, and the other development white papers for suggestions and best practices for developing ASP pages and other site components.

Consider using the Blank Solution Site shipped with Commerce Server to prototype your new site. Two additional Solution Sites (Retail and Supplier) are available for download from https://www.microsoft.com/commerceserver/downloads/solutionsites(fromCS2K).asp. All three Solution Sites provide examples of best practices for coding sites with Commerce Server. Consider using a Solution Site as the basis for coding your site if your site is sufficiently similar to it, rather than migrating code and components from your existing site.

Note   Even if you use a Solution Site as the basis for developing your site, you will have to migrate user and product catalog data.

The site development process consists of the following steps:

  1. Port Web pages from Site Server to Commerce Server
  2. Develop new components or pages
  3. Configure migration tools
  4. Modify sample code for tools
  5. Run migration tools
  6. Unit test all new code
  7. Perform integration testing
  8. Perform acceptance testing at full scale and load in staging area

The tools in the following table can assist you with migration.

Use this tool To
SQL Server Data Transformation Services (DTS) Process data before writing custom components. For more information about the SQL Server DTS tool, see SQL Server Books Online.
Membership Migration tool Migrate user data from the Membership Directory to stores used by the Commerce Server Profiling System. This tool is available in the Commerce Server 2000 SDK.

For more information about this tool, see the "Personalization and Membership" topic later in this white paper.
Ad Server Migration tool Migrate data and schedules. This tool is available in the Commerce Server 2000 SDK.
Transaction Migration tool Migrate transaction data. This tool is available on the Commerce Server 2000 Resource Kit CD.
Catalog Migration tool Import a catalog from either an XML file or a comma separated values (CSV) file. You must first write code to export your SSCE custom catalog into one of these formats.

The script MigrateCatalog.vbs, which is located on the Commerce Server 2000 Resource Kit CD, is an example of a catalog import script for importing the Volcano Coffee catalog. It provides a migration path from a SSCE online store to a Commerce Server catalog. For more information about migrating a catalog, see the VCTurbo_CS2K folder on the Commerce Server 2000 Resource Kit CD.

Migrating Site Server 3.0 Features

Most Site Server 3.0 features have corresponding features in Commerce Server and the Microsoft Windows Server System environment. However, some features, including ACM, Tag Tool, and Content Analyzer, do not.

This section provides tips for migrating the following Site Server 3.0 feature areas to Commerce Server:

  • Analysis
  • Content management
  • Knowledge management
  • Personalization & Membership

Analysis

Commerce Server contains the following components for performing business analysis:

  • Data Warehouse
  • Business Analytics System

The Commerce Server Business Analytics System and Data Warehouse features are not compatible with the Analysis package found in Site Server 3.0. Commerce Server has many standard reports that might meet your reporting requirements. If you need custom reporting capabilities, you can write your own (for examples, see the topic "Extending Commerce Server" in the "Creating Custom Reports" topic in the Commerce Server 2000 SDK). There are also a number of vendors who provide comprehensive reporting products that work well with Commerce Server. For information about these vendors and their products, see https://www.microsoft.com/commerceserver/.

You can also create new reports by using information in your log files. For more information, see Commerce Server 2000 Help. If you need to import custom data into the Data Warehouse and report on it, you must create a custom DTS task to import the data before you create a custom report to report on the data.

To maintain continuity, you must import existing logs into the Data Warehouse. You need to import only enough data to satisfy your existing trending periods. For example, if you usually track performance for 90 days, you need to import 90 days' worth of historical data into the Data Warehouse.

The following table describes the migration path for Site Server analysis features.

Feature Migration path
Analysis– Import Data Warehouse. To migrate, you do the following:

Save log files.

Import log files (for last n days).

Create custom-import DTS scripts, if necessary.
Report Writer Business Analytics System. The Commerce Server 2000 SDK provides examples of several types of custom reports.
Content Analyzer No equivalent functionality.

Figure 6 shows a timeline for migrating the Analysis functions from Site Server 3.0 to Commerce Server 2000.

Ee824045.migratingcode6(en-US,CS.10).gif

Figure 6. Timeline for migrating Analysis functions

Content management

You can use Site Packager and Application Center to deploy content. The following table describes the migration path for Site Server content management features.

Feature Migration path
Content Replication (deployment) Use Site Packager to deploy simple site installations.

Use Application Center to replicate content over a local area network (LAN).

Use the (CRS), which is shipped with Application Center, to deploy on a wide area network (WAN).
Posting Acceptor WebDAV.
Publishing Wizard No equivalent functionality.
Tag Tool No equivalent functionality.

For information about how to deploy content by using the Commerce Server platform, see the white paper titled Deploying Content.

Knowledge management

Commerce Server contains the following knowledge management components:

  • Commerce Server Direct Mailer
  • Catalog search
  • Site terms

This section describes how to migrate the following Site Server knowledge management components to Commerce Server:

  • Direct Mail
  • Search
  • Site Vocabulary

Commerce Server contains no equivalent functionality for the following Site Server knowledge management components:

  • ACM/ACS
  • Knowledge Manager

Direct Mail

Commerce Server Direct Mailer is faster and more scalable than the Site Server 3.0 Direct Mail function. In addition, it is easier to integrate and manage, and you can personalize it. The following table describes the migration path for Site Server Direct Mail features.

Feature Migration path
Dynamic distribution lists Migrate users, then create a dynamic report of the users by using the Commerce Server Business Desk Reports module. Import the list of users into the List Manager module from the Reports module.
Static distribution lists Export static distribution lists from the SSCE Membership Directory to a CSV file for import by the List Manager module. Use the following format: 
Mailto, [GUID], [message format], [language], [URL]

Use the StaticExport.vbs script on the Commerce Server 2000 Resource Kit CD as a prototype for creating CSV files for import into the Direct Mailer database.

Figure 7 shows the Direct Mail conversion process.

Ee824045.migratingcode7(en-US,CS.10).gif

Figure 7. Direct Mail conversion process

Search

Site Server provides the following three types of searches:

  • Catalog searches. The Commerce Server Product Catalog System provides search capabilities on product catalog information. In addition to improved scalability and performance, it also supports probabilistic ranking, "find similar," and natural-language queries. If you use SQL Server 2000 with Commerce Server, you also receive free-text search capabilities without adding an external search engine.
  • Intranet searches. Windows 2000 Index Server provides search capabilities for intranet search. The Commerce Server Business Desk Help Search feature uses Index Server. For more information about Index Server, see https://www.microsoft.com/ntserver/web/techdetails/overview/IndxServ.asp.
  • Internet searches. Neither Commerce Server nor Windows 2000 Index Server provides Internet search capabilities. For information about companies who provide capabilities for Internet searching and indexing for use with Commerce Server sites, see https://www.microsoft.com/commerceserver/.

Site Vocabulary

Commerce Server provides a site terms feature, which you use to create a list of specific values pertinent to your site. You then assign each value to a profile property as the property type. For example, you can create a site term named City, then display possible locations in a drop-down list from which customers make a selection. The site terms feature is a flat structure. To migrate from Site Server 3.0 Site Vocabulary (which is a hierarchical structure) to Commerce Server site terms, consider the following options:

  • Flatten the hierarchy of your Site Vocabulary structure.
  • Re-create Site Vocabulary entries as site terms.
  • Use SQL Server for large Site Vocabulary trees.

Personalization & Membership

Commerce Server contains the following components that map to certain SSCE Personalization & Membership features:

  • Profiling System
  • Expressions

This section describes how to migrate the following Site Server Personalization & Membership features to Commerce Server 2000:

  • Authentication
  • Dynamic Directory
  • (LDAP)
  • Membership
  • Personalization
  • Rules

Authentication

Commerce Server supports the following authentication modes:

  • Windows authentication. AuthFilter controls site access through access control lists (ACLs).
  • Custom authentication. Using AuthFilter basic services, you create a custom authentication process to control site access.
  • Autocookie. Anonymous users can access the site. AuthFilter generates a persistent cookie (MSCS Profile ticket) to track an anonymous user.

For more information about AuthFilter, see Commerce Server 2000 Help. For more information about authentication, see the white paper titled Deploying Your Site.

If you store user IDs and credentials in Active Directory, you can use any form of authentication supported by Windows 2000 and IIS 5.0, including the following:

  • NTLM
  • Kerberos
  • Digital certificates
  • Basic HTTP authentication
  • HTTP forms authentication
  • Cookie authentication
  • FormsAuth

If you want to use data in the Membership Directory for authentication, you must migrate it to Commerce Server.

**Note   **Distributed Password Authentication (DPA) is not supported; however, Commerce Server works with Passport. For more information about Commerce Server/Passport interoperability, see the topic "Extending Commerce Server" in the "Integrating with Passport" topic in Commerce Server 2000 Help.

Dynamic Directory

Site Server ILS Services is now available in Windows 2000 Server. It replaces the Site Server ILS Services/Dynamic Directory. Note that the current version contained in Windows 2000 Server does not support replication between service instances, so it is not a true fault-tolerant system. If you used the Site Server ILS as a store for session state information, and your Commerce Server site requires the same functionality, store your data in a SQL Server 2000 database to maintain high availability. If you choose to use the Windows 2000 Server ILS, you must re-create your ILS/Dynamic Directory schema when you migrate from Site Server to Commerce Server. For more information about using Windows to migrate Site Server ILS Services/Dynamic Directory to Commerce Server, see the Windows 2000 Resource Kit.

LDAP

If your site has an application that requires LDAP, it can continue to use the LDAP interface to Active Directory, as long as the attributes the application needs are located in Active Directory.

Membership

The following table lists options for migrating your Membership Directory from Site Server to Commerce Server.

Migration option Description
Windows 2000 Server Active Directory
  • Active Directory is required for ACL/access control entry (ACE)–based access control to static content through group permissions.
  • Active Directory is the best option for storing attributes that don't change often (for example, names).
  • Active Directory is necessary to support deployments requiring access control of files that map to groups of users.
  • Performance is better when you have large volumes of read activity, with minimal write activity.
  • Active Directory provides better security than SQL Server. Commerce Server takes advantage of Windows 2000 security if you use Active Directory.
SQL Server
  • SQL Server relies on the application to control content.
  • Support for groups is limited to approximately 200 members, due to the way group information is stored.
  • Tune SQL Server for equal read and write performance.
  • SQL Server is supported for authentication.
  • SQL Server is the best option for managing data that changes frequently (last visit, favorites, and so on).
Combined Active Directory and SQL Server
  • The combination of Active Directory and SQL Server 2000 provides both access control (Active Directory) and enhanced performance for data that changes often (SQL Server).
  • In this scenario, you store data associated with user credentials and other stable data in an Active Directory store. You store the remaining attributes in a SQL Server database.
LDAP
  • The Commerce Server Profiling System only supports using LDAP stores as a property store.
  • CS Authentication doesn't work with LDAP providers.

The following steps outline the process for migrating your Site Server Membership Directory to Commerce Server. For more detailed information about migrating your Membership Directory, see the description of the Membership Migration tool in the Commerce Server 2000 SDK.

  1. Determine whether you need on-demand user migration (in which you migrate users on a real-time basis as they log on to your site) or batch user migration (in which you migrate the entire user database and use a batch method to download the data).

    If you need on-demand migration, you can install the migration objects on the Web servers and use the sample Login.asp as an example of how to trigger a migration on demand.

    If you need batch migration, you can install the migration objects on a stand-alone server, then start the sample client to move users.

  2. Decide which members and which attributes to migrate. This is an excellent opportunity to review and revise your membership structures, if necessary.

  3. Determine which Membership Directory attributes are used for all current users.

  4. Create Commerce Server user profile equivalents for the Membership Directory user attributes you want to migrate.

  5. Modify the Membership Migration tool, if necessary.

  6. If necessary, migrate groups using the Membership Migration tool.

  7. Create a migration-configuration XML file by using the Migration ProfileBuilder helper function of the Membership Migration tool.

  8. Design tests and test a small population of users.

  9. Reapply ACLs on Commerce Server files and directories, as appropriate, after groups are migrated.

The following table shows which property stores provide features comparable to those found in the Membership Directory.

Option Active Directory SQL Server LDAP
User properties Yes Yes Yes
Authentication Yes Yes No
Groups Yes Yes No
File access control Yes No No

Figure 8 shows the timeline for migrating the Membership Directory.

Ee824045.migratingcode8(en-US,CS.10).gif

Figure 8. Membership Directory migration timeline

The timeline in Figure 8 shows that preparatory work is completed prior to migration. Migration occurs after the Commerce Server site begins functioning.

Membership Migration tool (Directory Migration Toolbox)

You use the Membership Migration tool (Directory Migration Toolbox) to migrate membership data from Site Server to Commerce Server. You can use it for incremental migration of user profiles (on demand, as users log on), in addition to batch migration. This means that users can log on and be migrated in real time, even when batch migration mode is running in the background. This removes the need to take your site offline when you migrate the Membership Directory.

Figure 9 shows the architecture of the Membership Migration tool.

Ee824045.migratingcode9(en-US,CS.10).gif

Figure 9. Membership Migration tool architecture

The Membership Migration tool is structured as a set of Component Object Model (COM) objects and configured by means of an XML migration profile. In addition, the Membership Migration tool includes the source code for all of the components so that you can modify them to meet your needs. After you install Commerce Server, you can access the source code for these components at Microsoft Commerce Server\SDK\Tools\Membership Migration by selecting SDK, and then using the Complete option or Custom option.

Although the Commerce Server Profiling System supports groups, the implementation depends on the capability of the Profiles data store. You must use Active Directory to implement groups the same way they were implemented in your Site Server Membership Directory.

You can use Active Directory to create groups and assign ACLs and ACEs to files and directories. However, the implementation is not identical. Active Directory limits a group to 5,000 objects. This limit is necessary because of the manner in which the contents of the group are replicated between instances of the domain controllers. Although this limitation will be addressed in future versions of Active Directory, in the meantime, consider it when you migrate your Membership Directory.

You can use the Membership Migration tool to create subgroups, and then add user profiles to the subgroups. To preserve space for additional growth and subgroups, the tools fill 4,500 user profiles per subgroup.

**Important   **You must set up Active Directory in native mode. Do not set up Active Directory in mixed mode; if you do, Active Directory will not create the required hierarchy of the groups.

Personalization

The Commerce Server UserProfile object replaces the Site Server Active User Object (AUO). The UserProfile object is compatible with IADs Active Directory Service Interfaces (ADSI) interface, and should be instantiated in the Global.asa file. For more information about the UserProfile object, see Commerce Server 2000 Help. For more information about ADSI, see https://www.microsoft.com/windows2000/techinfo/howitworks/activedirectory/adsilinks.asp.

The Commerce Server Profiling System provides the following functions:

  • Abstracts data location
  • Integrates with the Targeting System and the Business Analytics System
  • Evaluates expressions in run time

You perform the following steps to migrate from Site Server to Commerce Server:

  1. Migrate all code that uses the AUO to use the UserProfile object for each ASP page.
  2. Instantiate the UserProfile object in the Global.asa file.

Rules

Commerce Server expressions are named conditionals that evaluate to True or False. Commerce Server expressions combined with ASP pages are equivalent to Site Server rules. Expressions provide better reuse than rules.

Business Desk contains the Expression Builder, which is fully integrated with the Targeting System and the Content Selection Framework (CSF). To migrate from rules to expressions, you must re-create rules logic as expressions and wrap the expression in ASP code. For more information about creating expressions, see Commerce Server 2000 Help.

Migrating SSCE Features

You can migrate most SSCE features directly to Commerce Server 2000. SSCE functionality is a superset of the Site Server functionality described in the previous section. This section provides tips for migrating the following SSCE feature areas to Commerce Server:

  • Ad Server
  • Online store
  • Pipelines
  • Predictor
  • Promotions
  • Transaction data

Ad Server

In Commerce Server, functionality corresponding to SSCE Ad Server has been moved to the Targeting System and is accessed from within Business Desk instead of running as a stand-alone management interface, as it did in SSCE. The Ad Server system has been extensively revised.

To migrate Ad server functionality from SSCE to Commerce Server, do the following:

  • Migrate ad data
  • Migrate ad schedules
  • Change ad tags to expressions

Use the Ad Server Migration tool, AdServerMigration.exe, to perform your migration and recode Site Server rules as Commerce Server expressions. The Ad Server Migration tool is available in the Commerce Server 2000 SDK in the SDK\Tools\Migration\Ad Server path in the Commerce Server installation folder.

Online store

The Commerce Server Product Catalog System is very flexible. It can support imports by means of XML files, CSV files, or catalog application programming interfaces (APIs). To migrate your SSCE online store to a Commerce Server product catalog, do the following:

  1. Create a new catalog in the Product Catalog System.
  2. Map your online store structure to your catalog structure. The Volcano Coffee Turbo (VCTurbo)_CS2K folder, located on the Commerce Server 2000 Resource Kit CD, provides an example of how to do this mapping. The VCTurbo site is a sample site created to demonstrate a performance enhancement to the Volcano Coffee site originally included with SSCE. The script MigrateCatalog.vbs, which is available on the Commerce Server 2000 Resource Kit CD, migrates the (VCTurbo) catalog from an SSCE online store to a Commerce Server 2000 catalog. The script migrates the catalog by directly calling the catalog APIs.
  3. Export your SSCE online store to an XML file, including the following:
    • Products and Product Attributes to the Commerce Server catalog
    • Product families to Commerce Server product definitions
    • Departments to Commerce Server categories
  4. Import the XML file into the Product Catalog System.

To migrate the VCTurbo catalog, do the following:

  1. Create definitions.
  2. Associate a product ID.
  3. Create variant values.
  4. Create a new catalog.
  5. Create a department.
  6. Migrate product information.

Now you can use Business Desk to manage your newly migrated catalog.

VCTurbo does not use Personalization & Membership; it uses shopper tables. Therefore, this migration example does not migrate your users. You can migrate users with the Membership Migration tool.

Pipelines

You use pipelines to serialize actions that result in a completed order. For a detailed description of all the pipelines that Commerce Server offers, see Commerce Server 2000 Help and the Order Processing sitelet in the Commerce Server 2000 SDK. There are also several sitelets in the SDK that might be helpful to you as you plan your migration.

The following Site Server pipelines have changed in Commerce Server:

  • Order Processing Pipeline (OPP): The Commerce Server OPP API is the same as it was in SSCE. However, most of the underlying pipeline data structures have changed. There is a backward-compatible mode available so that existing pipeline components can be used in the Commerce Server site. However, when you run in compatibility mode, you have to run the entire pipeline in compatibility mode. You can't select compatibility mode at the stage level.

    If the existing pipeline component uses data in the dictionary, it will function as expected. The only data types and formats that have changed are addresses and currency. If the old pipeline component looks for data in a specific location or database table, however, you must rewrite it to use the new data storage locations used in Commerce Server. If possible, use pipelines in native mode to take advantage of the new features of COM+, such as object pooling.

  • Commerce Interchange Pipeline (CIP): BizTalk Server has replaced the SSCE CIP pipeline. For information about BizTalk Server, see https://www.microsoft.com/biztalk/.

Predictor

The Commerce Server Predictor resource provides intelligent and automatic selection of cross-promotional items by correlating the items that a customer has ordered with a database of items that similar customers ordered previously. The Predictor resource examines the database to find orders that are similar to the current customer's order and generates a list of recommended products, ensuring that none of the products are already in the current customer's order.

In SSCE, the predictor engine was usually used in conjunction with the intelligent cross-sell function. In Commerce Server, the role of the Predictor resource has been greatly expanded to support the following application scenarios:

  • Product area recommendations
  • User cluster visualization
  • User attribute prediction

Wait to create prediction models until your new Commerce Server site has been in production for several weeks, because the Predictor resource requires data from the Data Warehouse that was not tracked in the Site Server analysis engine.

Promotions

Commerce Server supports the types of promotions listed in the following table.

Promotion type Description
Cross sell A type of promotion in which customers are presented with a list of products related to products they have already purchased. This feature is part of the Product Catalog System.
Intelligent cross sell A type of promotion in which customers are presented with a list of products based on past purchase behavior and the products they are currently viewing or have added to their baskets. You use the Predictor resource to implement intelligent cross-sell promotions.
Discount A type of promotion in which shoppers are invited to save money on products or product groups if they meet certain conditions (such as two items for the price of one or discounts for members of a purchasing group). In Commerce Server, discounts have a targeting component and a display component. The Commerce Server 2000 SDK contains a sitelet demonstrating how to implement various discounts.
Up sell A type of promotion in which shoppers who have purchased one type of item are urged to upgrade to a better version. For example, a shopper who has purchased silver jewelry is shown the same item in gold.

Transaction data

It is technically possible to migrate SSCE transaction data to Commerce Server 2000. The Commerce Server 2000 Resource Kit CD contains a Transaction Migration tool to help you migrate your transaction data from SSCE to Commerce Server.

The primary reason for converting transaction data is that you can use a single console (Business Desk) to handle customer support issues. You can also have historical information available for generating reports. If you don't need this data, or if you can obtain it through an existing application, it's probably not worth the effort to move the old data.

If you decide to migrate SSCE transactions to Commerce Server, use the Transaction Migration tool. The Transaction Migration tool migrates only transaction data (orders and receipts). Transaction data depends on customer and product data, so you must migrate all customer and product data before you use the Transaction Migration tool to migrate transaction data.

Figure 10 shows how you might migrate transaction receipts, using the Transaction Migration tool.

Ee824045.migratingcode10(en-US,CS.10).gif

Figure 10. Migrating transaction receipts by using the Transaction Migration tool

Deploying

The "Migration Strategies and Scenarios" section earlier in this article contains a step-by-step scenario for migrating to Commerce Server from a Site Server platform. In addition to that section, review the sources for deployment information listed in the following table.

Source Contains
Commerce Server 2000 Help Suggestions for configuring hardware in addition to information about how to use Business Desk, Commerce Server Manager, and other key Commerce Server components.
Deploying Content white paper Best practices for deploying a Commerce Server site.
https://www.microsoft.com/commerceserver/ Latest updates on migration issues and information about third-party vendors.
https://www.microsoft.com/technet/ Information about Windows 2000, SQL Server 2000, Commerce Server, and best practices. Select the product you want from the Navigate by Product drop-down list on the left side of the screen.
https://www.microsoft.com Downloads of tools.
Commerce Server 2000 Resource Kit CD Downloads of tools and code examples.
Commerce Server 2000 SDK Code samples, sitelets, and other deployment assistance.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.

© 2000 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, BizTalk, Windows and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

© Microsoft Corporation. All rights reserved.