Microsoft Commerce Server 2000: Migrating from Site Server to Commerce Server 2000

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, including its 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 services to interact with Commerce Server as a collection of ASPs, 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 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 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 the 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 user name, password, address, telephone number, e-mail address, and all other available data. 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 using either Active Directory or a Microsoft SQL Server database. If your site requires authorization and a security context for each user, then 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 Commerce Server 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, while 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 11.1.

Cc936689.f11csrk01(en-US,CS.10).gif 

Figure 11.1   Migration timeline

Planning the Migration

 Cc936689.spacer(en-US,CS.10).gifCc936689.spacer(en-US,CS.10).gif

As you plan how to migrate your site from one application to another, be sure to read this chapter 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)/middleware components

Content deployment

Using 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 SQL Server 7.0 or 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 should 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/technet/archive/itsolutions/intranet/downloads/webstres.mspx 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?

  • 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 and 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 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. Microsoft Office Web tools are used by Business Desk 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/technet.

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).

Site Server/SSCE features

Commerce Server 2000 features or related resources

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 who provide capabilities for Internet browsing, see https://www.microsoft.com/technet.

Site Vocabulary

Site terms (flat structure).

Tag Tool

No equivalent functionality.

Transactions

Use the Transaction Migration tool found on the Commerce Server 2000 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, you should 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, you should keep the following migration strategies in mind:

  • 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 trade-offs between 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. Later, you can add other Commerce Server features.

  • Upgrade SSCE to a Windows 2000 Server platform using Site Server 3.0 Commerce Edition, Service Pack 4 (SP4). This will make your migration easier because Commerce Server requires Windows 2000 Server. Windows 2000 provides a 30 percent to 100 percent performance improvement for SSCE sites, as well.

  • Migrate your 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 going into 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 access to additional hardware, network, and physical infrastructure on a short-term basis 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 using Commerce Server to act as your pre-production environment. Figure 11.2 shows the state of the network during Phase 1.

Cc936689.f11csrk02(en-US,CS.10).gif 

Figure 11.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), with no changes yet. The following work 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 the Ad server

    • Configure the Personalization & Membership feature

    • Configure the Web server(s)

    • 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 your test environment (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://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx.

    • 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 on the T1 environment. Figure 11.3 shows the state of the network during Phase 2.

Cc936689.f11csrk03(en-US,CS.10).gif 

Figure 11.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 do 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 an 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 have to 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 chapter 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 use by the Analysis modules and Predictor resource. 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 using the Transaction Migration tool found 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 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 you have a fully functional pre-production environment up and running, the next step is to move the Commerce Server site into production. Figure 11.4 shows the state of the network during Phase 3.

Cc936689.f11csrk04(en-US,CS.10).gif 

Figure 11.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://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx) to test load against the new production site. 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. For more information about TCA, see Chapter 19, "Maximizing Performance."

  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 goes live.

  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 (T1) and the test environment (N1)).

  8. During a period of minimal usage, change the DNS and/or Single Internet Provider (IP) 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, roll DNS/single IP back 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 should be able to 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, user information changed during the time the Commerce Server site was in production will not be reflected back to the old SSCE-based site.If you used the Membership Directory in conjunction with your old SSCE-based site, you should 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 11.5 shows the state of the network during Phase 4.

Cc936689.f11csrk05(en-US,CS.10).gif 

Figure 11.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 (P1) environment 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 you have a fully functional Commerce Server production (T1) and test environment (P1), you can decommission the old test/staging site (N1), dismantle the hardware, and return it 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 should describe 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 before moving the new software into production, including stress and load testing. 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 moving your new site into production.

Failure while moving your site from the test environment into the production environment

Create a plan for immediately reverting back 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 can be readily re-imported by the old site. This might require tool development and should be considered when estimating the development effort.

Developing

 Cc936689.spacer(en-US,CS.10).gifCc936689.spacer(en-US,CS.10).gif

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 chapters in this book 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/technet. 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 like one of them, 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 still 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 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 "Personalization & Membership" later in this chapter.

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 Extensible Markup Language (XML) file or a comma-separated value (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. Also, 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 Active Channel Multicaster (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 "Creating Custom Reports" in the "Extending Commerce Server" section in Commerce Server 2000 Help). 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/technet.

You can also create new reports 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 Data Transformation Services (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:

  • 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 11.6 shows a timeline for migrating the Analysis functions from Site Server 3.0 to Commerce Server 2000.

Cc936689.f11csrk06(en-US,CS.10).gif 

Figure 11.6   Timeline for migrating Analysis functions

Content Management

You can use the Commerce Server 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 Content Replication System (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 using the Commerce Server platform, see Chapter 15, "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 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, in 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 11.7 shows the Direct Mail conversion process.

Cc936689.f11csrk07(en-US,CS.10).gif 

Figure 11.7   Direct Mail conversion process

Site Server provided 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 the Index Server. For more information about Index Server, see https://www.microsoft.com/technet.

  • Internet searches. Neither Commerce Server nor Windows 2000 Index Server provide 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/technet.

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

  • Recreate 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

  • Lightweight Directory Access Protocol (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 Chapter 14, "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 Internet Information Services (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 "Integrating with Passport" in the "Extending Commerce Server" section in Commerce Server 2000 Help.

Dynamic Directory

Site Server ILS Services are now available in Windows 2000 Server. It replaces the Site Server ILS Services/Dynamic Directory. Note that the current version shipped 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 recreate 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 access control list (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 (such as 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 leverages 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 would store data associated with user credentials and other stable data in an Active Directory store. You would 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 in to your site) or batch user migration (in which you migrate the entire user database, using 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 across.

  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 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 supported

Yes

Yes

No

Groups

Yes

Yes

No

File access control

Yes

No

No

Figure 11.8 shows the timeline for migrating the Membership Directory.

Cc936689.f11csrk08(en-US,CS.10).gif 

Figure 11.8   Membership Directory migration timeline

The timeline in Figure 11.8 shows that preparatory work is completed prior to migration. Migration occurs after the Commerce Server site goes live.

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 in), as well as batch migration. This means that users can log in 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 to migrate the Membership Directory.

Figure 11.9 shows the architecture of the Membership Migration tool.

Cc936689.f11csrk09(en-US,CS.10).gif 

Figure 11.9   Membership Migration tool architecture

The Membership Migration tool is structured as a set of 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 you can modify them to meet your needs. The source code for these components is located at Microsoft Commerce Server\SDK\Tools\Membership Migration after you install Commerce Server using the Complete option or Custom option with SDK selected.

Although the Commerce Server Profiling System supports groups, the implementation depends on the capability of the Profiles data store. You must use the 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 completely the same. 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, you might have to perform a work-around to migrate your Membership Directory in the meantime.

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 groups hierarchy.

Personalization

The Commerce Server UserProfile object replaces the Site Server Active User Object (AUO). The UserProfile object is compatible with the IADs 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 functionality:

  • 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.

  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 expressions 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 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 Volcano Coffee Turbo (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 to the Commerce Server catalog

    • Product attributes

    • 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 VC Turbo catalog, do the following:

  1. Create definitions.

  2. Associate product ID.

  3. Create variant values.

  4. Create new catalog.

  5. Create a department.

  6. Migrate product information.

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

VC Turbo 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/technet.

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 have 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 so 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 across.

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 11.10 shows how you might migrate transaction receipts, using the Transaction Migration tool.

Cc936689.f11csrk10(en-US,CS.10).gif 

Figure 11.10   Migrating transaction receipts with the Transaction Migration tool

Deploying

 Cc936689.spacer(en-US,CS.10).gifCc936689.spacer(en-US,CS.10).gif

The "Migration Strategies and Scenarios" section earlier in this chapter 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 as well as information about how to use Business Desk, Commerce Server Manager, and other key Commerce Server components.

Deployment section of this Resource Kit

Best practices for deploying a Commerce Server site.

https://www.microsoft.com/technet

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.

Cc936689.spacer(en-US,CS.10).gif