Migrating from ASP.NET 1.0/SQL Server 2000 to ASP.NET 2.0/SQL Server 2005

You can upgrade to SQL Server 2005 in-place or migrate your database to SQL Server 2005 instance. Upgrading becomes easy if there are only a few breaking changes that need to be addressed. The article Upgrading the Database Engine which is subset of Upgrading SQL Server Components focuses on database engine upgrade and considers different types of complex systems.

A proper strategy needs to be decided for sequence of upgrading the various database servers. We had a separate backup server and we upgraded it only a week after main server was upgraded. The complications increase with failover clusters and replications. So an architect will need to sit down with the DB team and chalk out the actual schedule or and strategy for database upgrading the database system.

One also needs to take a decision with respect to following settings of database

1. Setting compatibility level to SQL Server 2005
2. Setting database options
3. Setting row versioning feature
4. Capability Planning for tempdb

All the above decisions are important and will impact the overall success of database upgrade.

Also, please note that the Query Execution Plan of SQL Server 2005 is different from previous version and may result in weird behavior for the queries executing properly in previous version. So some time should be allocated for troubleshooting and query tuning such scenarios. These need to be handled on a case-by-case basis.

2.1.4.3 Infrastructure

In upgrade process infrastructure plays an important role and should be given due attention to avoid last moment issues. If system is in Production then one must have a similar environment to test the upgrade process. Quite often UAT machines do not have the exact configuration as that of Production. This situation should be rectified.

The infrastructure strategy can impact the rollback plan. For example, the rollback strategy can change if you have a separate environment for deploying the upgraded system. Generally upgradation of server is done in-place. So infrastructure team should careful and ensure that necessary service packs are available for installation. The sequence and schedule for upgrade of various software and tools needs to be finalized and should be conveyed to corresponding stake holders. Necessary security verification and acceptance should be obtained in advance to avoid last minute issues.

Also, the developer machines may need additional disk space and RAM, since both VS 2003 and VS 2005 need to co-exist during the upgrade process. So automated testing and performance testing may need separate installations / setups for both 1.1 and 2.0.

2.1.4.4 Testing

The eventual success of an upgrade depends a lot on Testing. Normal system or integrated testing and upgrade system/integrated testing have distinct difference. For a normal release there can be a couple of rounds of testing, but during an upgrade many rounds of system testing may be needed depending on number of issues and their occurrences across the system. This is due to the fact that most of the runtime and UI related issues are identified and fixed only during system testing.

While testing, we also need to ensure that the functionality of the system is not affected. Now it is quite possible that the testing team may identify an existing defect (a defect that already exists in system before upgrade). To maintain focus, it is advisable to concentrate only on defects introduced by the upgrade, while existing application defects should be kept aside till all upgrade defects have been addressed. This will ensure that the upgrade process is smooth and manageable.

A problem for the testing team is that there are quite a number of differences in the response rendered by ASP.Net 1.1 and ASP.Net 2.0. So you cannot use existing automated test scripts and performance test scripts with ASP.Net 2.0. This can impact you in two ways - one, you may have to rely on manual testing for the upgrade release and second, you may have to develop automated scripts for ASP.Net 2.0 once again. So it is very important that you plan the testing properly and have sufficient effort allocated for the same.

During an upgrade, you may need to conduct more than 2-3 rounds of system testing. A defect found during system testing may need to be fixed across the application. So you may need to test the application once again.

The testing should cover all functional test cases of each module, all batch processes, all up-stream / down-stream data transfer and even stored procedures which are used by backend only. The interfacing with other systems should also be tested. The update of test cases and test plans should be done as needed. The testing strategy should also take into consideration the rollback and infrastructure strategy to finalize testing plan.

2.1.4.5 Rollback Strategy

The rollback strategy is a critical aspect during an upgrade owing to the inherent risk involved in the entire process. The rollback plan should be foolproof and should be able to restore the system to the exact point before the upgrade. Of course we are referring to the rollback of the upgrade of a system which is already in production. It is quite possible that the rollback may take more time than the deployment of upgrade release.

Depending on upgrade strategy for infrastructure and database upgrade, we can carve the rollback strategy. If there are two separate environments in production for the different versions, there will not be very difficult to rollback. But if we are upgrading the Production server in-place, rollback becomes more complex. Clustered environment or replication also adds complexity to rollback.

Another aspect for consideration is partial or full rollback. What I mean by full rollback is that the old system is completely restored. So even if a single thing goes wrong, we have to rollback all the system components. In partial rollback we may choose to rollback only a few affected components, which may be upgraded later once the issue has been addressed. For example, if we find a problem with the database upgrade, then we can choose to continue with the upgraded .Net application. So the system will work with ASP.Net 2.0 and SQL Server 2000.

We picked the option of full rollback while planning for the upgrade because we did not want additional complications. If partial rollback is to be considered, then the testing strategy will need to cover the combination of technologies as indicated above.

One should not take an ad-hoc decision on partial rollback. It is more risky and should be considered after proper analysis has been done. Following are some of the important factors which can affect the rollback strategy:

• Availability of separate environments
• Involvement of software installations in upgrade
• Interoperability of various versions of software
• Complexity of application configuration
• Availability of time for deployment
• Availability of skill set of deployment team
• Possibility of partial rollback

2.2 Execution of Upgrade Activities

Once the decision for upgrade has been taken and all strategies have been planned, a proper schedule has to be finalized for upgrade activities. The planning involves schedules for:

1. Necessary software installations like VSTS 2005, SQL Server 2005, Enterprise Library, Web Application project setup etc.
2. Base lining of code for upgrade and creation of separate branch/folder in version control
3. The execution of Wizard for upgrade will be done by single person and then the files should be distributed for design time breaking changes
4. Fixing of design-time breaking changes are followed by fixes for runtime breaking changes
5. Planning for configuration changes for deployment on development box
6. Testing releases and test case planning
7. Planning for defect fixing
8. Planning for rollback and documentation of the corresponding strategy
9. Release note documentation

The upgrade process should be monitored at all times as any unforeseen issue may arise and can consume a considerable amount of time. So time and resource management are crucial.

Our discussion on the execution of upgrade activities can be divided into three sections - upgrading using wizard, post upgrade changes and testing.

2.2.1 Upgrading application using wizards and tools

ASP.Net application upgrade-activities

Before executing the upgrade wizard please make sure that:

• There are two separate environments available to you. You should able to access and verify old code and functionality.
• You should baseline your code and database scripts before upgrade starts.
• Ensure that all necessary software and components are installed on your box.
• The ASP.Net solution and project folder should contain only files from Source Control. It should not have any temporary or extra files.
• You should be able to open the solution in VS 2003 and can compile and work with it, even after installing the latest components on your system.

To upgrade .Net solution from .Net 1.1 to 2.0, open the solution using VS 2005. VS 2005 will identify the solution with old version and invoke the Upgrade Wizard. Follow the steps and complete the process. The wizard basically changes the project files and a few other files like DataSet files. Most class (.cs) files are left unchanged. In case of aspx and ascx files, if we are using Web Application project (recommended) then there are hardly any changes required. But if we go for Web Site project (not recommended), then wizard makes a lot of changes to these files as well.

An article Step-By-Step Guide to Converting Web Projects from Visual Studio .NET 2002/2003 to Visual Studio 2005 gives you details of upgrade steps for web application project conversion. I would personally recommend that you do not follow "Step 6: Covert Code-Behind Classes to Partial Classes". This will not result in the creation of separate designer.cs files and will not move control declarations to that file. This helps us to do comparing with old version also helps in merging of files. If needed, you should do this after all testing has been completed.

The details of other changes needed in solution are discussed in the next section.

SQL Server upgrade-activities

The SQL Server upgrade can be done in two ways - in-place upgrade or migrating backup.

Run SQL Server Upgrade advisor and make the necessary settings to server and database. Then you can carry out the actual upgrade of the database. The article has steps to install SQL Server 2005. Once the database upgrade is complete, one needs to make changes related to Database Options as per the agreed strategy.

In analysis phase we have already identified impacting breaking changes in database. We have to create necessary scripts to fix them. Execute the script on the database so that upgrade of database is complete and it may be used for application testing.

The remaining changes related to performance issues or query tuning can be taken into account while testing the application.

2.2.2 Upgrade code changes and defect fixing

ASP.Net application code changes and defect fixing

Once the wizard processing is complete we have to compile the solution. You might be surprised to note that there are no compilation errors. The real story starts after this. VS 2005 compiles the web project without any error, but you may get run time errors. This happens because compiler is not able to catch errors related to the designer.

We followed these steps to remove all design time errors:

1. Update html validation features of VSTS 2005 (it is advisable not to enable this at the initial stage). This setting is done using following menu of VSTS 2005 - Tools => Options => Text Editors => Html => Validations
2. Open each and every screen (.aspx/.ascx) in Design View.
3. If you get "Can't switch to design view" error, you may need to make the necessary changes in Code View. This error is encountered if VSTS 2005 is unable to find proper sequence of opening and closing tags of page
4. If you get "Ambiguous Declaration" error then it shows first line as location of error. You will encounter this error if you have duplicate Ids for the controls on the page. So you have to check all controls (including custom / user controls) on that page and modify as needed.
5. If you are using third party controls then you might get errors related to that component. So you need to apply fixes for them as per vendor suggestion.
6. Once you fix all the design time errors you have completed one milestone.

The Run-Time breaking changes need to be fixed very carefully. The fixing of each type of defect should tracked properly by maintaining list of files modified and using commenting tags in files where code has been modified. The analysis phase has already enlisted impacting changes. One needs to search for the occurrences of such breaking changes in the application and apply suggested fixes to the problem. You may come across a few runtime errors for which there may be no direct solution. So you may need to consider re-designing of an existing code block to fix the problem.

You also need to work on changes required for upgrade of components like Enterprise Library or Third Party controls or tools etc. The changes should be planned one at a time and need to be tracked properly. We had to make a number of changes in our Data Access Layer to use Enterprise Library 3.1. However, we were able to manage them easily as there were no other breaking changes in Data Access Layer.

For each defect we followed following sequence for fixing:

1. Each defect should be considered independently and fix should be applied one by one as far as possible.
2. Identify reason(s) for defect.
3. Gather different solutions for defect fixing. We mostly used breaking change work around, vendor suggestions, solutions suggested on internet and lastly trial and error methods.
4. Enlist all the files and occurrences of defect in application. Locating all occurrences of a defect is important. 100% coverage should be targeted.
5. Verify other occurrences for generic solution. Enlist occurrences which need a specific fix.
6. Finalize the approach to be used to address the defect. Identify special cases for which a different fix is needed.
7. Apply the fix for all occurrences.
8. Conduct sanity testing.
9. Check-in the code and send it forward for the next round of testing.
10. You may need to change the approach to fix the problem in certain cases depending on testing output. So defect fixing should be marked using proper comments to enable easy identification of the changes.

As I said earlier, there can be more than a couple of rounds of testing. The number of iterations depends on how efficiently you are able to locate all occurrences of an issue across application and what generic (and robust) solution you can provide for fixing it. Please ensure that your solution does not result in a new issue. Also you will need to cross-check each issue fixed in the application. This is very important as there is a possibility of oversight owing to the large number of occurrences.

SQL Server Script changes and defect fixing

The major work in SQL Server upgrade involves changes to the scripts which are not supported by SQL Server 2005. You need to identify all scripts which needs modification and re-write the script with given work around. The list is already available in analysis phase.

It is quite possible that you may face performance issue for some stored procedures after upgrade. Surprised? Well, it is possible. The reason for this is that SQL Server 2005 uses a different query execution plan as compared SQL Server 2000. Although this is a rare occurrence, it is possible that a query which has no performance impact with SQL Server 2000, takes a lot more time to execute with SQL Server 2005. The solution is simple - revisit the query and tune it as per SQL Server 2005.

Also, as mentioned in strategy section, you may need to make some changes to the Database Options. You may also need to identify capacity for tempdb database. All these depend on strategy you decide in upgrading to SQL Server 2005.

2.2.3 Functional and performance testing of system

This is an important activity in an upgrade and success largely depends on this. You will usually conduct manual testing. You may need more than a couple of rounds of testing during this phase. So you should plan your resources accordingly.

The testing phase starts after you have a reasonably stable build available with you. It is very important you check the necessary changes in server configuration and .config files during each deployment before testing. While carrying out the testing, you must have an active deployment of the previous version, which forms the baseline for your testing. The failed test cases should be cross checked with this deployment to identify whether they are related to the upgrade or are existing defects in the application.

The testing can be done for one or more of the following purposes:

1. Testing functional working of screen -
   The main focus is on functional output of screen. All functionality must be working correctly as per test cases. In upgrade testing, it is very important to know which control is not behaving as per expectation. This helps us to find reason for defect quickly.
2. Testing UI appearance of screen -
   Here basically we compare screen layout and appearance between old and new versions. It is quite possible that you may observe that the style sheet classes are not being applied properly or grids look different. This may happen if you have used third party controls which has new features and requires proper implementation for CSS classes. Or it may happen because of changes in behavior and layout of upgraded control.
3. Testing of screens for fixed defects -
   You may need to test certain screens for which one or more defects have been fixed. You may need both functional and UI testing of such screens depending on fix applied.
4. Testing of batch processes and back end data updates -
   Most of the times you use back end processes to do batch functionalities. You need to verify that all batch processes are working correctly and are giving expected results. You may encounter a problem where batch is executing properly, but presentation layer is not displaying is correctly because of some runtime error in UI Layer. This also helps to check the compatibility and integration with other related components. Please note down all configuration changes done to back end processes.
5. Testing of interfaces and data transfer from upstream and to downstream -
   In upgrade it is very important that you do not have any issue with other related systems. If your system is using interfaces with another system or transferring data across a different system, you should take necessary steps to verify that the activities and batch jobs are working fine with the new set up.

Performance Testing

Upgrade should also satisfy performance criteria. So performance testing should be conducted and all bottlenecks should be tuned. The performance result before software upgrade should be used as a baseline. I have already mentioned that performance scripts need to be recreated for ASP.Net. The capturing of the scripts should be done only after upgrade build has been stabilized. This is because in case any major defect is found after capturing the scripts, then it may be necessary to capture them all over again.

Performance tuning can be needed at Presentation layer, Data Layer or SQL Queries. You may use profiler to tune the functionality or flow. If you are using third party controls that are upgraded, then ensure that they are not impacting the performance. Caching should not interfere with any third party controls used in the application.

Similar to performance scripts, it is necessary to capture scripts for automated testing once again. The script capturing should again be done on a stable build. The testing should be done in accordance with rollback strategy and should identify the actual configuration changes required in production.

2.3 Deployment Activities

This preparation becomes important if system is in production. The deployment note or release note for upgrade is much more complex and in detail. It should have all details of software to be installed, all configurations to be done and complete rollback plan.

2.3.1 Release notes and Server configurations

The release note of upgrade deployment consists of following details:

• Backup activities for existing setup and data of Web/App Server and database
• Software versions to be needed for upgrade (and if required, location of setup too)
• Sequence of installation and verification methodology to check installation is done as per expectations
• Configuration to be done for each software
• IIS configuration for ASP.Net 2.0. This includes registering .Net 2.0 with IIS and settings related to Application Pool if required.
• Web site or Virtual Directory configuration for ASP.Net 2.0
• Application (with new version) deployment steps.
• Configuration file changes for application (web.config and other related configuration files).
• Configuration or setup needed for third party controls/components.
• Guideline for rollback like full rollback or partial rollback.
• Sequence of Rollback activities to be done that includes
  • Restoring of backup of old deployment (may be needed in case of rollback)
  • Reconfiguring of old deployment in case of rollback
• Contact details of stake holders to handle any unexpected situations.

Even though the release note has all the details about backup and configuration settings and rollback details, IT team or deployment team should be involved in preparation of this release note. IT team should be aware of all the settings and steps needed for upgrade release. This ensures that all participants have the same understanding and any unexpected issues at the time of deployment can be handled efficiently.

The configuration changes should be done carefully. The configuration changes on Web server are related to:

• Enterprise Library related changes (if Enterprise Library is upgraded).
• web.config or app.config changes for timeouts and performance (if any).
• Machine.config changes for performance and timeouts, if any (Please note that you need to make changes in the machine.config file of .Net framework 2.0 again. The new framework has an auto-configured performance setting. You can use that option in machine.config).
• Custom config file changes, if any.
• If deployment is on a separate server, then you have to copy all necessary files to the respective folders.
• If you are deploying on the same server, then you also have to mark unwanted config files for deletion.
• On database server you have to configure database options as per agreed strategy.

2.3.2 Rehearsal of Deployment Activities

Usually for a maintenance or enhancement release, the deployment rehearsal is done on the UAT box where basically we deploy the application and change a few settings. But for an upgrade release, the deployment is much more complex. So it is very important that we rehearse the deployment (including rollback activities).

The deployment document or release note should cover all necessary details for deployment and rollback. The rollback plan should be executed on UAT so that all minute details are captured and known to IT team. This gives confidence to IT team and management, while also ensuring better time management during the release.

All software stake holders should be notified about activities in deployment and rollback. Necessary consent should be taken in advance for the steps to be followed during the deployment of the upgraded version of the software.

2.3.3 Production Deployment or Go Live

This is the final stage in an upgrade process wherein the upgraded application is deployed in production environment. It is very important to choose deployment dates such that the Business Impact is minimal. As mentioned earlier, it may take more time than the normal deployment procedure.

If we are able to simulate the deployment in an environment exactly similar to that of production, then there is obviously a reduced risk of unforeseen issues cropping up during the actual deployment in the production environment. But it is possible that one or more patch may not be installed in the production environment or some supporting assemblies may not be available. We must be ready to turn-around such issues immediately if they occur.

One of the important factors to be considered during deployment is to take the decision for rollback just in case something goes wrong. It is very important that we take the right decision for rollback (if at all required) in the minimum possible time (but not until we have ascertained that problem cannot be solved immediately). The decision is usually driven by the type of problem encountered and the time available to tackle it.

3 Conclusion

It has been a great experience to upgrade the system from ASP.Net 1.1 to 2.0 and SQL Server 2000 to 2005. Effective analysis of system and proper monitoring of the process helped us take timely decisions and plan accordingly. We faced quite a number of unexpected issues which I have already mentioned in above sections.

Finally, strategy planning, monitoring and timely decisions hold the key to success of an upgrade. Hopefully, our experience may help minimize your troubles during an upgrade process.

I would be very happy to hear from you about your upgrade processes and usefulness of this article.