Chapter 5 — Planning Phase: Clients

Article
12/05/2007

Published: June 21, 2004 | Updated: October 29, 2004

Introduction and Goals

Chapter 3, "Planning Phase: Overview," outlined the principal tasks involved in planning, and Chapter 4 discussed planning the database migration. This chapter focuses on migrating the client applications. It provides guidance to help you make the necessary decisions and consider the pertinent issues in the context of creating the solution design. You will begin with the conceptual design and then develop the logical and physical designs, and these will all become part of the functional specification for the project. Detailed project plans for how the team will accomplish the migration are covered in Chapter 8, "Planning Phase: Creating the Project Plans."

The term client in this chapter is used to refer to database clients: any part of the application that accesses the database. In some application architectures, these parts of the application may be referred to as middleware servers, application servers, or some similar term: the logic in a Web server used to access a database is an example. The use of client in this chapter does not refer to parts of the application that do not directly access the database, such as desktop client applications or browsers that expect a server to handle the database connection.

The goals of planning the client application migration are to:

Identify applications that can or cannot be successfully migrated to the new environment.
Identify the various technologies that are used to build the Sybase client applications that you want to migrate.
Identify the technology challenges that your migration project must address to redirect or rehost the client applications selected for migration.
Examine these technologies to better understand the roles that they play in the application.
Determine whether there is a feasible, cost-effective way to resolve these challenges.
Select the methods for each application's migration solution from available options, based on current and replacement APIs.

By the end of this chapter, you will have assembled a roadmap for your application projects based on the methods you select for each application's migration (re-hosted or redirected). Record these decisions; they will be used when creating your development plan and other plans that will become part of the master project plan (see Chapter 8).

Note There are often complex dependencies between databases and the applications that use them. Therefore, planning for client application migration should be performed in conjunction with planning the database migration. For more information about planning database migration, see Chapter 4, "Planning Phase: Database."

Developing the Solution Design and Architecture

Sybase client applications are often run from UNIX scripts such as Perl, C (csh) and Korn (ksh) shell. This document takes advantage of Microsoft® Windows® Services for UNIX (SFU) version 3.5 as the platform on Microsoft Windows that supports many UNIX applications, utilities, tools, and shells, including csh, ksh, and Perl. This document refers to the UNIX Application Migration Guide for many areas of scripting and application migration guidance. You can access the UNIX Application Migration Guide at https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnucmg/html/ucmglp.asp.

Developing the client solution requires choosing among specific solutions for each client. Your clients and applications may each be built on common or differing underlying technologies. These technologies are more commonly found as application programming interfaces (APIs), embedded in libraries from Sybase or possibly other vendors of similar libraries. Client applications may also take advantage of other third-party libraries for communications, graphical interfaces, or specialist processing (for example, mathematical libraries for performing statistical analysis). Planning involves performing an assessment of each application in your environment to determine the specific needs of that application. You can find much of this information by referring to your existing design documentation, if it is available. If this documentation does not exist, you will need to examine the project source code and any automated build scripts or makefiles, which will provide information about the libraries that are linked into the binary for the application.

Client Application Migration Options

There are two basic approaches that you can take to migrating client applications: redirecting the existing application or rewriting the application.

Redirect the Existing Application

Redirecting the existing application to use SQL Server instead of Sybase is attractive because it involves only minor modifications to the code in the client application. Clients communicate with both Sybase and SQL Server over a protocol called the Tabular Data Stream (TDS). TDS is a protocol, a set of rules describing how to transmit data between two computers. Like any protocol, it defines the types of messages that can be sent, and the order in which they may be sent.

Originally, both Sybase and SQL Server databases used the exact same version of the TDS protocol. However, in recent years, different revisions of the protocol have been developed. Sybase ASE 12.0 and later databases use protocol version 5, while SQL Server 2000 uses protocol version 8. Earlier versions used version 4.2.

Three different APIs have been developed over TDS:

DB Library. This is the API originally developed by Sybase that contains methods that client applications can use to submit SQL queries and retrieve the results. SQL Server and Sybase shared a common implementation of DB-Library in the past but, in recent years, both products have diverged significantly.
CT Library. This is also known as Sybase Open Client client library. Although designed by Sybase for their own database, it was also intentionally made database-generic, and works against SQL Server 2000 if the client is well-behaved (that is, it checks whether a facility is available before using it).
ODBC. This was developed by Microsoft as a generic database access API. There are both Sybase and SQL Server 2000 ODBC drivers available.

Which API your application uses and what features it requires of the database dictates the level of recoding required for a simple retargeting of the database.

Note Java applications that make use of Sybase JDBC drivers can, in theory, be moved directly to Windows and reconfigured to use an appropriate SQL Server JDBC driver. However, you will need to ensure that such applications do not make use of any Sybase-specific functionality exposed through JDBC because these parts may need to be rewritten.

Important You cannot redirect client applications that make use of the Sybase BCP (bulk copy) functions in DB-Library to connect with SQL Server.

Rewrite the Application

Rewriting the application for Windows makes use of native SQL Server APIs, ADO.NET, Microsoft ActiveX^® Data Objects (ADO), or Open Database Connectivity (ODBC) running natively in the Windows subsystem. This option can result in a more stable and integrated configuration after the project is complete.

Redirecting an existing application, or totally rewriting the application for Windows, are the two extreme ends of the range of migration solutions. In reality, you will find that migrating a Sybase client application to use SQL Server often encompasses options that require both these scenarios; you might find that parts of a system require redirection while other components need complete rewriting.

The scope of this guide is primarily focused on redirecting clients that are based on DB-Library ,CT-Library or ODBC from Sybase to SQL Server. If your applications are based on DB-Library , CT-Library or ODBC and other third-party libraries, this guidance applies to you. However, you may need to adapt specific requirements for your third-party libraries into the provided guidance framework.

Client applications are limited to using the communications features exposed by the version of whichever library that they are compiled against and linked to. For example, the most recent Sybase implementation of DB-Library does not provide the same capabilities as the Microsoft implementations of DB-Library; client applications that you redirect to communicate with SQL Server will not be capable of utilizing the full capabilities of SQL Server.

Note Although the DB-Library and Embedded SQL for C APIs are still supported in Microsoft SQL Server 2000, future versions of SQL Server will not include the files needed to create applications that use these APIs. Connections from existing applications written using DB-Library and Embedded SQL for C will still be supported in the next version of SQL Server, but this support will be dropped in a future release, and will be available only through third party implementations such as FreeTDS. Avoid using these components when writing new applications. When modifying existing applications, you are strongly encouraged to remove dependencies on these technologies. Instead of DB-Library or Embedded SQL for C, you can use ADO, OLE DB, or ODBC to access data in SQL Server.

Choosing the Migration Strategy

For each application identified by the assessment questionnaire, use the questionnaire data to make a preliminary decision regarding the most appropriate migration strategy for that application. The summarization of all these decisions constitutes the conceptual design. The aggregate of these designs, along with logical grouping of applications becomes the logical design of the migrated applications. The physical design describes the specific systems on which the migrated applications will reside.

Figure 5.1 illustrates the decision-making process you can follow to determine which application migration approach you should use for each application.

Figure 5.1 Determining the migration approach for each client application

Note In the decision-making process shown in Figure 5.1, if you arrive at the box titled "No Solution – Migrate to SQL Server API," there are many options to look at. The following links reference APIs for Windows Server 2003 and SQL Server 2000 applications development, respectively: https://www.microsoft.com/windowsserver2003/developers/default.mspx, and https://www.microsoft.com/sql/techinfo/development/2000/default.asp.

Migration of Sybase client applications can include the following tasks:

Migration of client application code
- DB-Library API
- CT-Library API
- ODBC API
Migration of UNIX-based support scripts
Migration of UNIX cron tasks for job automation and control

Note cron is the name of the UNIX job scheduling utility.

Application Concepts

The conceptual design of migrated client applications should be very similar to the original conceptual design of the original applications. Unless you are extending or amending the application as part of the migration process, you should be able to gain an understanding of the requirements of the migrated application based on the functionality of the existing system. The questionnaires and other information gathered earlier in the Planning Phase will provide a good source of information, as will the experience of the staff supporting the existing system.

The results from the server and database questionnaires from the assessment survey should provide this information. Each API is associated with specific migration issues that will affect your migration plan. After you have identified the APIs that the application uses, you can begin to plot your strategy to migrate each particular technology to the SQL Server platform. As you review the survey results, group your applications into the following API categories:

DB-Library clients
CT-Library clients
Open Server clients
ODBC clients

You might find that your migration plan needs to encompass multiple strategies to address all of the technologies present in your current environment. Be aware that each strategy will affect your plan differently. Choose the migration options that best address the goals of your project. The following sections offer guidelines on how to choose the right migration strategy for a particular technology.

DB-Library Clients

Sybase applications that have been built using DB-Library have four migration options:

Full migration to Windows. This involves a complete redesign and redeployment of the application to take advantage of the Windows APIs. Guidance for performing a full migration is beyond the scope of this guide.
Redirection using Sybase DB-Library. This involves leveraging your existing applications on the current platform (this requires continued Sybase licensing fees for network and client licenses).
Redirection using FreeTDS. This involves leveraging your existing applications on the current platform using FreeTDS to redirect them to SQL Server.
Utilizing Windows Services for UNIX and FreeTDS. This involves moving the applications to exploit SFU on the Windows platform and using FreeTDS to access SQL Server.

These options will be described in more detail in the "Logical Design" section of this chapter.

CT-Library Clients

Sybase CT-Library client applications use Sybase Tabular Data Stream (TDS) 5.0. This version of TDS was created by Sybase, and Microsoft does not support it. Consequently, client applications that use CT-Library will not connect to SQL Server. However, FreeTDS allows client applications built using CT-Library to communicate with SQL Server provided that they do not employ functionality that is not available in SQL Server. This means that you only have three options available for connecting Sybase applications that use CT-Library to SQL Server:

Full migration to Windows. This involves the complete redesign and redeployment of the application to take advantage of the Windows and .NET APIs.
Redirection using FreeTDS. This involves leveraging your existing applications on the current platform using FreeTDS to redirect them to SQL Server.
Utilizing Windows Services for UNIX. This involves leveraging SFU on Windows platforms to enable moving these applications using FreeTDS to access SQL Server.

As before, these options will be described in more detail in the "Logical Design" section of this chapter.

Open Server Clients

Sybase Open Server is an API for building middle-tier applications that expose a Sybase database server interface to clients. There are no SQL Server APIs compatible with the Sybase Open Server API. However, FreeTDS does include an implementation of the Open Server interface, though it is less complete than any of the client libraries. The best practice is to rewrite the Sybase Open Server applications using appropriate Microsoft technologies.

When Open Server APIs are found in a Sybase migration, you must perform a detailed analysis to determine the exact services that the Open Server methods provide so as to mimic those services in the appropriate SQL Server technologies, and to evaluate if FreeTDS Open Server is an option. SQL Server offers more built-in functionality, is more versatile, and can replace the services that the Sybase Open Server provides. Windows COM+ objects can mimic extended stored procedures, and you can use linked servers to replace the functionality of the Sybase Open Server technology itself.

Scripting Concepts

You must assess UNIX scripts for any required changes to embedded paths as a result of the migration or relocation of the scripts onto SFU. Of course, it is possible that any number of changes may be required to the scripts involved. It is also possible that changes may not be required if paths on the SFU platform mirror those found in the current environment and nothing else requires changing. The csh and ksh shells in SFU are fully compliant with established standards. For more information about SFU and how you can employ it in your environment, see the Microsoft Windows Services for UNIX Web site at https://www.microsoft.com/windows/sfu/default.mspx.

For more information about migrating UNIX scripts, see the UNIX Application Migration Guide at https://msdn.microsoft.com/library/en-us/dnucmg/html/ucmglp.asp.

The following list represents a starting point for issues that you will have to address when migrating UNIX scripts:

Paths and installation folders. It is possible that these may not require any changes if paths on the SFU platform mirror those in the current environment and nothing else changes.
Executable names and file names. You will need to check file names against file naming conventions supported by Windows.
Environment variables. The names and values of any environment variables used by the application will have to be mapped from UNIX to their Windows equivalents.
Configuration files. The names and locations of any configuration files used by the application must be mapped correctly to Windows.

If UNIX cron plays a role in the current enterprise, examining the crontab entries will actually tell a great deal about job control activities that may require duplication in the migrated environment. Different versions of UNIX have their own methods for utilizing cron. Please consult the man pages for the platforms that you need to assess. UNIX cron is a standard component of SFU.

Note In many cases, UNIX cron jobs can be replaced with scheduled SQL Server Agent tasks.

Logical Design Considerations

The logical design for a database migration project must take into account the changes that will occur as a result of moving from Sybase to SQL Server. At a minimum, you should consider the following key items:

Dependencies between client applications and databases, including network communications, database permissions, and authorization
Use of UNIX scripts in support of client applications
How data in the databases is secured

Examining the conceptual design of the client application will give you an understanding of how it operates and is structured. You may now consider the options available for migrating the application to make use of SQL Server instead of Sybase.

Figure 5.2 suggests a process to follow to develop the logical design of the migrated applications:

Figure 5.2 Developing the logical design for migrated applications

UNIX Scripts Supporting Client Applications

Most database environments use scripts to support both databases and client applications. For example, many UNIX application developers use scripting languages, such as Perl, the Bourne Shell (sh), Korn Shell (ksh), and C Shell (csh), to simplify complicated startup and shutdown tasks, supply command arguments, and reference external files.

Shell scripts are typically started from cron, or manually invoked to perform their tasks. It is important to evaluate the importance of the services that these scripts perform from the standpoint of the client’s actual functionality.

The following options are available for migrating UNIX scripts to operate against SQL Server running under Windows:

Rewrite the scripts using an appropriate Microsoft technology. Typically, this will mean using Windows Scripting Host (WSH) and Microsoft® Visual Basic®, Scripting Edition (VBScript) to convert the batch jobs. These tools support the flow control processing that is typically found in the UNIX scripts, but which is not available in the Windows Command shell. Further information about WSH is available at https://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/wsconwhatiswsh.asp. Perl scripts can be run under ActiveState’s port of perl to Windows.
Migrate the scripts to SFU 3.5. SFU provides Perl, and the Korn Shell and C Shell command interpreters that are equivalent to those found on all UNIX platforms. Existing scripts should require few or no changes to run under SFU. However, scripts that make use of Sybase utility programs, which are not available under SFU, must be modified to use suitable replacements; FreeTDS provides tsql and freebcp as open source replacements for Sybase isql and bcp. The DBD::Sybase and Sybperl modules can be configured to connect to SQL Server through FreeTDS instead of Sybase by setting the SYBASE environment variable appropriately

In both cases, you should perform the following tasks:

Identify the scripts that support the Sybase client applications that you are migrating.
Review the job and scripts questionnaire results from the assessment surveys discussed in Chapter 3, "Planning Phase: Overview," to identify the scripts that you should migrate.
Determine the scope of this part of the migration.
If appropriate, redevelop (port) the scripts for the Windows or SFU platform as outlined earlier.

Your migration plan should specifically address the effort required for rewriting scripts if that action should become necessary.

Redirection Strategy

Redirecting a client application enables that application to connect directly to SQL Server. This section covers several approaches for redirecting clients and applications.

Redirecting a client often requires changes to the source code of the application. There are two items that you should look for:

Connection String Data. This information comprises the specific logon, password, and database/host. This is the approach you can use when moving, for example, Java applications that use JDBC. Connection string information can be encoded in several ways:
- The connection string is hard-coded. To redirect the connection to SQL Server, you must identify the client applications that use this method and plan to manually code the new strings. You will need to map the user names and passwords to the name of the new SQL Server. It is important to rigorously test applications migrated this way. You should rely on the test specifications used when the applications were created and reperform those tests.
- The application uses a configuration file that holds the connection string. To redirect the connection to SQL Server, edit the configuration file that each application opens and change the host name and database instance name. The scope of this effort is application-dependent because multiple applications can talk to a single database. You may need additional information before modifying configuration files.
- The application uses a command line argument. It is common for the command line arguments to come from scripts that also need to be migrated. Assessing the scripts that start the application being redirected is required at this time.
- Environment variables may be used to supply connection data. The user environment under Windows will need to be modified to incorporate the necessary variables.
Tabular Data Stream (TDS) Compatibility Flag. DB-Library supports a compatibility flag that applications can set that defines the version of TDS the application will use for communicating with the database server. The TDS Compatibility Flag is set using the dbsetversion DB-Library function call.

Note It will not be necessary to change the compatibility flag if the application was built using DB-Library version 4.2 or earlier.

SQL Server 2000 and Sybase also exhibit some differences in the way in which the same Transact-SQL statements behave. For example, the following SQL statement returns the value

when executed against a SQL Server 2000 database, but returns the value FakePre-5383a55d044b418fba9949b0f8905d4f-ea460af3b7b24eb58c8f3a6dad1b6e2e when executed against a Sybase ASE 12.5 database:

select datalength('')

There are a number of other differences as well. Dependencies on features such as these can cause a redirected client application to malfunction. You may need to change the compatibility level of the SQL Server database to exhibit the same behavior as earlier versions of SQL Server (and Sybase) by using the sp_dbcmptlevel stored procedure. For more information, see Appendix D, "Transact-SQL Behavioral Differences."

If you do need to modify the source code of the application, you will need access to the following resources:

Application source code (all modules)
Required libraries or object files (APIs)
Makefiles or scripts to build the executable code
Software development system (compiler, assembler, linker, debugger)
Original design specification or design documents
Development systems; for example, operating system, developer tools, documentation tools

Additional tools, software libraries, licenses, or other components of your system may also need to be located and utilized to accomplish redirecting the intended client application.

Note Sybase client license fees apply to redirected applications.

Configuring FreeTDS

If you are using FreeTDS to redirect the client application, you must supply information about the address of the server and the version of TDS to use in the FreeTDS configuration file. Under UNIX and SFU, this file is called freetds.conf and is typically located in the /usr/local/etc directory. Each entry in this file is identified by a unique server name string, and you can dynamically direct a client application linked using FreeTDS to a specified entry by setting the DSQUERY environment variable to the corresponding server name. This process is described in more detail in Chapter 10, "Developing Phase: Clients."

Editing the Sybase Configuration File

An alternative approach for redirecting existing clients that are known to use only TDS 4.2 and supported SQL Server functionality is to modify the Sybase directory services configuration file and modify the entry pointing to the Sybase server with the address of the SQL Server database server instead. Microsoft supplies a Perl script called db_ver.pl that you can use to test that the modification has been made successfully. This script is part of the Sybase Migration Toolkit (SMT).

The db_ver.pl script is run with arguments:

--user=<username>

or FakePre-4da20288169f4558afef84ec691339e0-918ba9f7e1ee45c2ab6e8f3c6de10a79

--password=<password>

or FakePre-1cad711bf9314e708eaf0103a7d27a50-98b084c003f944a2b1758717a3f5672b

--system=<instance name>

or FakePre-81b242c442334785a78798a9a517768f-b1c35473aa4642ba9b2e1e618906ae06

Note that if a password is not specified, the program will prompt for it. Modifying the Sybase configuration file and the entry pointing to the Sybase server is the most transparent form of redirection, but also the strategy that is least likely to work; many existing applications will have been built using more recent versions of DB-Library or CT-Library, which will not connect to SQL Server without modification.

Using ODBC

There are two popular Open Source ODBC driver managers available for UNIX and Linux platforms: unixODBC and iODBC. These provide a middle ground for applications that need to run in a UNIX or SFU environment, where DB-Library or CT-Library are unsuitable. Both unixODBC and iODBC are UNIX implementations of ODBC. They are both driver managers, which means they provide the main interface to your application, but they call different plug-in drivers to communicate with the database. Both are available for SFU from the Interop Systems Web site: https://www.interopsystems.com. Although the driver managers are largely interchangeable, this guide usually refers to unixODBC.

You can replace DB-Library and CT-Library function calls in applications with the equivalent ODBC function calls (this requires careful design and a good understanding of the architecture of ODBC). You will also need to procure and install a suitable ODBC driver for accessing SQL Server; FreeTDS contains a reasonably complete ODBC driver. Use of ODBC is described further in Chapter 10, "Developing Phase: Clients."

Version Issues in the Development Environment

It is important to assess the impact of versioning issues between the original and current development environments. Can you build the application from source with the tools and libraries currently available? Does the built system behave exactly as the current production system? Do you have any existing tests to help prove the system?

If current development tool versions are not capable of rebuilding the application code, the development environment itself may not allow redirecting. Determine the extent of change between the current and historic development environments to determine whether the source code will build in the new environment. For these applications, a rewrite strategy may be the only strategy.

If your assessment confirms that version compatibility issues exist, you have two options:

Fall back to a previous version of the development environment in which the original application was developed.
Find out from the makefiles or scripts used with the original source code which version of the libraries were used and determine whether the new environment will support those libraries. If not, you may need to try linking the applications to the old libraries.

If the client application uses third-party libraries or alternative connection methods, this may require further steps or solutions unsupported by Microsoft.

Consult documentation for any third-party APIs that are employed by the client application for possible change requirements that might affect your code or strategies when redirecting.

Note Automating changes of the type described here introduces considerable risk. Therefore, choosing an automation strategy for source code changes is not recommended.

Physical Design Components

The physical design encompasses the hardware and software on which the logical design is implemented. You should consider the following items:

Client hardware that will host the application after it has been migrated
Operating system and other software running on the client hardware that supports the migrated application
Connectivity requirements of the client hardware to the SQL Server database

The following sections will help you plan for a migration by identifying the various components of the physical design and outlining the typical design considerations that are contained within a migration plan.

Client Hardware

Because the term “client” in this guide refers to any client of the database and may well include server parts of the application, there are at least two choices for database access. These choices are discussed in the following paragraphs.

When client applications are hosted by desktop computers, accessing the database servers occurs across the network, typically using TCP/IP over Ethernet. In many cases, the choice of desktop hardware is dictated by the existing machinery. The capabilities of such existing hardware may need to be considered when determining whether to rewrite or redirect applications.

When the client is a server application running on a centralized resource, it may be that the database server is hosted on the same hardware. In such cases, local communications, such as Windows named pipes, can be used to access the database. Regardless of whether you plan to host the client and server on the same system, you

will need to estimate the CPU speed, memory usage requirements, and disk space requirements of your application apart from the database server requirements. If the client and server are to be cohosted, you will need to add both sets of requirements together.

It is important to understand both the bandwidth (the speed in bits or bytes per second you need to move between the client and server) and latency (how long it takes to get data from the client to the server and vice versa) requirements of your application when determining this part of the physical layout.

It is also vital at this point to review your security requirements; data isolation requirements often make substantial changes to the physical architecture.

Operating System

As with the client hardware, the choice of operating system for the client computer may sometimes be constrained by the existing configurations on users' desktops. The design of the application must take any restrictions into account.

Connectivity Requirements

Client applications redirected from UNIX computers must be capable of connecting to SQL Server running on Windows. The network infrastructure must support the required connectivity and protocols.

Note FreeTDS and unixODBC require that TCP/IP is enabled on the client computer and SQL Server.

Tools to Use

You may need the following tool to facilitate and manage the migration process:

Windows Services for UNIX (SFU) 3.5. SFU provides all of the features of a traditional UNIX operating system, including pipes, symbolic and hard file links, UNIX networking, and optional UNIX graphical support using X-Windows. It also provides UNIX and POSIX utilities such as csh*,* ksh*,* awk*,* vi,* *and hundreds of others.

The following tools may be required if you are redirecting Sybase client applications to use SQL Server:

FreeTDS (DB-Lib, CT-Lib or ODBC)
unixODBC or iODBC driver manager

The Physical Design Diagram

The physical design diagram allows you to see how all the components connect together. For completeness, it may include infrastructure elements outside of the scope of the project.

It will help prove the security of the system (or at least highlight its weaknesses), show potential throughput bottlenecks, and highlight single points of failure.

The following diagram shows a typical physical design diagram. Your design considerations may require you modify this example.

Figure 5.3 Sybase Client Migration Physical Design

Validating the Technology

Technology validation will usually involve prototyping and evaluating the tools to be used.

Technical Proof of Concept

Before you engage in a full Sybase client migration, you should consider developing a prototype project for the migration. There are a number of activities that could take place during the project, such as:

Deploying tools and building a development and a pilot environment
Testing the migration or porting techniques by selecting a large-enough source base and a complex-enough build environment
Verifying the migration approach, testing tools and procedures, and building confidence in the planned solution

Each activity has a bearing on the overall success of the migration process. You should handle prototyping activities particularly carefully. Prototypes set the tone and expectations for the rest of the migration. Because of this, it is very important that the organization have a positive and successful experience. A prototype project should be initiated as a test case for the larger migration project, enabling you to confirm that the staff, techniques, and procedures are all up to the task.

A proof of concept selects a specific aspect of the migration that, when implemented in a test environment, sufficiently proves the validity of the migration strategy. It is important to analyze your particular environment to figure out which client applications exercise the most rigorous functionality requirements in the system. You migrate these applications in the test environment and analyze the results to determine whether the migration was successful or, if problems are identified, how to resolve them. This process often reveals unexpected elements and other factors that could not be predicted. Strategies for resolving these issues must be incorporated into the migration plan.

Avoid rushing to start a proof of concept or prototype subproject until you understand exactly what you are trying to prove by doing it. While you may learn some valuable lessons by having failures, you may also disenchant the stakeholders, alienate the users, and set yourself up for overall failure. However, a proof of concept can answer some fundamental questions such as, “Is simple retargeting the database an option?”

Baselining the Environment

Establishing a baseline includes not only ensuring that you have up-to-date copies of all the software components that make the original system, but that you understand and have documented how that original system behaves, particularly with respect to performance.

Migrated applications must run at least as fast under Windows as they do under UNIX. You can measure performance by using benchmarks, or basing tests on subjective analysis when no benchmarks are available.

The UNIX environment will exhibit certain performance characteristics. The characteristics of the environment used by the migrated application will be different. You need to anticipate these differences and describe metrics to verify that the performance of the migrated technologies meets your objectives. For example, you might define a specific amount of data that is returned in a known time frame under the UNIX system and use that as one baseline metric for the new system. You should consider baselining any characteristics that provide performance measures for the CPU, memory, and disk use.

Interim Milestone: Technology Validation Complete

At this point, you should have evaluated the options that are available and decided on a strategy for migrating the Sybase client application (that is, rewriting, retargeting or rehosting). You should have decided which hardware and software platforms to use, and how to connect the client application to the server computers running SQL Server. You should have also determined how to measure the performance of the migrated application compared to the original implementation.

Updating the Risk Assessment

As with database migration planning, client application migration planning is likely to reveal additional risks that were not apparent earlier, or changed the impact of earlier perceived risks. You should ensure that the risk assessment document is updated accordingly.

Creating the Functional Specification for the Solution

The application must have at least the same features and functionality on the Windows platform as it does on UNIX. The functional specification for the migrated system should substantially mirror the functional specification of the UNIX solution in your current environment. It may also include any functional enhancements that you want to add as a result of the migration.

Note Functional enhancements are not recommended during the migration project itself, and should be considered a post-migration step. Changing the functionality will make it substantially harder to prove that the migrated system works as well as the old system, and greatly increases the risk for the project as a whole.

The Solution Feature Set

The feature set for your solution should include the documented services that the application provides that you intend to carry over from the current environment. It should also include any feature enhancements provided by the new technologies or that you have decided to incorporate into the migrated applications.

Interim Milestone: Functional Specification Baselined

At this point, you should have produced a detailed functional specification that describes how you are going to migrate your Sybase applications. You should also have defined the baseline capabilities and performance against which to assess the effectiveness of your migration solution.

Download

Get the Solution Guide for Sybase/UNIX to SQL Server 2000: Database Engine Migration and Application Interoperation Guide

Update Notifications

Feedback

Send us your comments or suggestions