1 Introduction
1.1 Overview
Upgrading an application is a crucial activity in an application life cycle. Every stage in upgrading has its own importance and criticality. Today I am sharing my experience on upgrading an ASP.Net application from 1.1 to 2.0 and SQL Server 2000 to 2005. There are lots of articles available on net which provide enough information on a particular component upgrade. I have tried to consolidate all such references under one roof where you can find a solution for all activities involved in an upgrade. I have broken down the upgrade process into the following stages:
- Decision and Planning an upgrade
- Identifying the need for an upgrade
- System analysis (to verify feasibility and estimate effort needed for upgrade)
- Decision to upgrade
- Strategies for upgrade changes, testing, rollback and deployment
- Execution of Upgrade Activities
- Upgrading application using wizards and tools
- Upgrade code changes and defect fixing
- Functional and performance testing of system
- Deployment Activities
- Release notes and Server configurations
- Rehearsal of Deployment Activities
- Production Deployment or Go Live
![UpgradeLifeCycle.JPG]()
My intention is not to tell you how to run a setup program or to run wizards. Rather, it is to make you aware of the various activities involved in an upgrade and their importance to achieve success. Identifying risks at an early stage is very important during an upgrade and can be achieved only by proper strategy and planning. You may face unexpected issues and have to be well prepared for fire fighting. The Microsoft Technology Center (MTC) of Infosys has various tools available that are very helpful in upgrade. So get in touch with MTC before you plan upgrade activities.
I will discuss all the steps one by one. Note that each system will have its own set of characteristics affected by an upgrade. As such, the decision and the subsequent activities in an upgrade may differ from one system to another.
1.2 Scope of this Document
The scope of the document is limited to various stages in the upgrade of an application to ASP.Net (Framework 2.0) and SQL Server 2005. The document also provides various links along with steps for specific activities like running a wizard to upgrade an ASP.Net application. It does not cover the intricate details of each step to be followed in upgrade process for a specific requirement.
Note that the necessary infrastructure requirements like parallel Web and Database servers with different version, or source control management for code of different versions are out of scope for this document.
1.3 Assumptions
It is assumed that the reader is aware of an ASP.Net web application, Microsoft SQL Server and Visual Studio fundamentals. He/she should have enough experience in development and deployment of web applications along with testing methodologies.
1.4 Target Audience
Target audience for this document includes:
- ASP.Net & SQL Server Application Design and Development team
- Application Architects, Designers and Senior Developers
- Application Management team
1.5 References
The following references have been used to provide additional inputs for this document
- Microsoft sites
- Microsoft Visual Studio 2005 Help Documentation
2 Upgrading .Net 1.1 to 2.0 and SQL Server 2000 to 2005
2.1 Decision and Planning for Upgrade
Upgrading an application to a higher version is always a challenge (both from the technological and management perspectives). Business should be convinced for upgrade as they may not be able to envision/quantify the gains. Usually, higher versions make code author's life easier by providing solutions out of box. The Decision and Planning for Upgrade is a crucial activity as it involves participation and acceptance from all important departments of company like IT, Finance, Compliance, Business and Application development team.
The initial three sub-sections of this section contribute towards decision making, while the last sub-section covers various strategies to be decided during an upgrade.
![Strategy.JPG]()
The decision making stage can be further sub divided into the following stages:
2.1.1 Identifying the need for an upgrade
The decision on system upgrade should be taken after considering various factors. One needs to analyze the benefits, while also considering the effort and risks involved. You may need to justify the need to upgrade to the business and finance departments.
Following are some of key indicators that you may use to identify the need for an upgrade:
- Increasing workload and degrading system performance due to the increased workload
- A sizable number of pending enhancements that can be addressed easily (and in a robust manner) by a higher version.
- The system has not been released yet and there is scope for an upgrade.
- It may also happen that the vendor has stopped or announced to stop support for the existing version of product used in the application.
There are a number of articles that discuss the new features and benefits of upgrading to .Net 2.0 and SQL Server 2005. The What's New article provides all new features of VS 2005. As compared to VS 2003 (.Net 1.1), VS 2005 (.Net 2.0) provides a number of additional features like:
- Enhanced C# and VB.Net languages
- Performance and functional benefits for Data Access with ADO.NET
- User friendly IDE targeting better productivity. The IDE provides excellent page designer, wizards, a refactoring tool, code analysis tools, testing abilities and a lot more.
- Integration with Database objects
- More efficient support for XML
SQL Server 2005 also has various new features and advanced capability to serve requests with optimal performance. The What's New in SQL Server 2005 article covers the new features of SQL Server 2005 while Database Engine Enhancements provides details of enhancements to database engine of SQL Server 2005.
The above details can help us make the decision whether there is need for an upgrade and help us understand how the new version can fulfill our need.
Usually, the initial decision on "Need for an upgrade" is basically driven by changes in "Non Functional Requirements" (NFR) of system and/or new enhancements demanding new features and the ability of higher version of software to fulfill these needs. At the end of this stage you can conclude whether system requires an upgrade or not.
If the decision is made to not upgrade the system, then the Upgrade Life Cycle ends here.
2.1.2 System analysis (to verify feasibility and estimate effort needed for upgrade)
Once we identify the "Need for an upgrade" it is also important to verify the feasibility of upgrading the existing system and estimate the effort required to upgrade the system. This is a time consuming activity and requires involvement from persons who know the system thoroughly. Before going into details let's take a look at the composition of a typical new version of software.
In general whenever a new version of software is released, it consists of:
- Fixes for the bugs in existing version
- New features or components
- Some old features may be deprecated
- Some old features may be removed or not supported in new version
- Compatibility or integration with other tools or software that are supported by existing version may or may not be supported
- Upgrade wizard or tool or utility to upgrade to new version
As part of feasibility analysis for an upgrade, we are not worried about new features, bug fixes or deprecated features. We are more concerned about breaking features and changes required to convert the application to new version. We are also concerned about the compatibility and integration support of new version with various other components already in use by the system. These are some of the important factors that can prevent us from upgrading our system.
Fortunately Microsoft has come up with excellent support for upgrading. It has provided an excellent wizard which easily converts the application from 1.1 to 2.0. It has also provided good documentation for breaking features and their workarounds. It has thus already prevented major headaches for us.
Does this mean that we don't have to do any work during an upgrade activity? Of course not, our work primarily involves analysis of the system to identify the impact of breaking changes and to provide solutions to address them.
Breaking features in .Net 2.0
.Net framework 2.0 has evolved with drastic changes from 1.1. It also has strict compliance norms for Object Orientated Programming. ASP.Net has undergone some fundamental changes where you can find different response as compared to the previous version.
When we are considering an upgrade from .Net 1.1 to .Net 2.0, we should correlate this upgrade with upgrade of IDE from Visual Studio 2003 to Visual Studio 2005 or VSTS 2005. So we should analyze the system considering both the framework and IDE changes.
The article Changes in .NET Framework 2.0 enlists all breaking changes for .Net Framework 2.0. The breaking features include:
- Design-Time Breaking Changes - Design-time breaking changes impact applications only when they are migrated from Visual Studio .NET 2002 or Visual Studio .NET 2003 to Visual Studio 2005, or when the application is just recompiled on the .NET Framework 2.0. They do not impact applications when they are run against the .NET Framework 2.0 but not recompiled.
- Run-Time Breaking Changes - Run-time breaking changes impact applications built against the 1.0 and 1.1 version of the .NET Framework when they run on the 2.0 .NET Framework. They can also impact applications originally built against the 1.0 or 1.1 .NET Framework and then recompiled on the 2.0 .NET Framework.
In both categories Microsoft has documented all changes related to sub categories like CLR changes, ASP.NET changes, C# changes or Xml and Serialization changes. The article mentioned above provides details about:
- What is the change?
- What is the impacted user scenario?
- What is the affected API?
- Severity of change
- Is there is any work around for the change?
The impact of these breaking changes on the application needs to be analyzed.
Breaking features in SQL Server 2005
The article SQL Server 2005 Database Engine Backward Compatibility provides compatibility issues with lower version of SQL Server 2005. This article provides details about four categories of changes done in SQL Server 2005. The list is as given below
Microsoft has also provided Upgrade Advisor utility tool to check the feasibility and changes required when upgrading to SQL Server 2005
The impact of above mentioned changes on database script need to be analyzed. All the stored procedures, tables, triggers or queries not compatible with SQL Server 2005 need to be modified. We also need to analyze infrastructure requirements with respect to SQL Server 2005 (like Capacity Planning for tempdb) which may impact overall performance of the application.
Upgrade of associated software, tools and components
Quite often, we use third party tools and components like third party web controls, Enterprise Library, etc in our application. We need to check impact of upgrade with respect to these tools and components. We might need to upgrade these components to higher versions as well. In such cases, we must check breaking features of these components as well.
In our project, we have also upgraded the Enterprise Library and Infragistics components. We had to make considerable changes in our application so as to be able to use latest versions of these components.
We continued to use SharePoint WSS 2.0 without any change. This decision was taken after complete analysis and testing compatibility with SQL Server 2005. The limited use of WSS 2.0 simplified our work. But you make need reconsider an upgrade if you are using many features of SharePoint Server.
You may also need to take into consideration the impact on the data transfer needs of the application from/to any upstream and downstream systems. It is a possibility that the data transfer tool may need to be modified or upgraded.
The compatibility & integration of various components of a system has always been a challenge to architects and the decision may vary on a case-by-case basis. It would be best if one could actually simulate the environment to check the compatibility and integration of new versions upgraded system. This helps to finalize the upgraded versions of various components of the system.
Considering Deployment/Business Constraints
This analysis is necessary if system is already in production. The upgrade process requires its own time frame. There will not be any new addition to business functionalities. So from business point of view, there may not be a direct benefit from an upgrade release.
However, it is important to note that it is risky to have parallel development of upgrade and maintenance/enhancement release. The upgrade release should not have any business functionality changes so as to avoid complications. The difficult part is convincing the business for a release which apparently gives them no business benefit. One should try to identify a lean period for the business so that a maintenance/enhancement release can be avoided, and the upgrade can be carried out smoothly. Of course, one can opt for a few enhancements in parallel with the upgrade activity. The code changes can later be merged with the upgraded application code either manually or using a tool. However, in this case, managing the entire process becomes quite crucial.
Another constraint is deployment or release dates or period. An upgrade release takes much more time than a normal enhancement/maintenance release. Also, sufficient time should be allocated for rollback, in case it becomes necessary.
The risks discussed above must be analyzed before taking a decision and chalking out a plan for upgrade. The analysis helps us verify the feasibility of an upgrade. It also helps in formulating the upgrade strategy and schedule planning.
At the end of this stage, we would have following details:
- Feasibility of system upgrade
- List of software, tools and components that need to be upgraded
- Details of versions to which software needs to be upgraded
- Impact analysis and approximate effort required for the upgrade
2.1.3 Decision for Upgrade
The outcome of previous steps determines the decision of whether the system upgrade is feasible or not. In case it is not feasible, the process ends here.
The upgrade process is separate release activity in which there is no enhancement to business functionality and requires considerable amount of time and effort for development and deployment. Business should accept the required downtime which may span from one day to three-four days or even more than that depending on integrated systems and deployments environments.
Following is a list of some decisions that are taken at this point:
- Is there a need to upgrade the system and do all stake holders accept the need?
- The required infrastructure and software versions are to be identified. Necessary steps to procure licenses are to be identified and timelines to be finalized.
- Steps to make infrastructure available are identified and accepted by respective stake holders.
- Approximate estimates of the work required for system code changes.
- Approximate time frame for the entire upgrade activity.
- Approximate downtime of system during deployment is accepted by stake holders.
- Decision related to parallel development is taken.
- All stake holders for infrastructure, upgrade development, testing, rollback, deployment teams accept the schedule for upgrade
- Initial stake holders for various strategies like infrastructure, upgrade development, rollback, testing and deployment are identified
The next stage is deciding and planning strategies for various components of the upgrade process. The decisions taken in this stage become guidelines for finalizing strategies.
2.1.4 Strategies for Upgrade changes, testing, rollback and deployment
Strategies for various upgrade activities play an important role in the entire process. These strategies help to finalize upgrade schedule with all required details and avoid chaos and confusion. In this section we will discuss strategies and corresponding upgrade plans.
2.1.4.1 Application Code Upgrade and Changes
Microsoft has provided a wizard to convert code to higher version of the .NET Framework. But we still need to make a number of changes in the code files (especially web pages and web user controls). The important decision is to go for either Web Site Project or Web Application project. When we migrate from VS 2003 it is recommended to upgrade to Web Application Project which is similar to VS 2003. An article Introduction to Web Application Projects helps you to decide whether Web Application project should be used.
When you use Web Application Project, do not convert the web page format to web Application format. This helps comparing and merging web pages with older versions. If needed, it is possible to change the format quite easily in the future.
The analysis of system has already identified breaking features which need to be fixed. It is very important to locate all code sections so that nothing is missed. Review is crucial, and can be done only through proper tracking of files for particular fix. I would recommend that one should target only breaking changes in during an upgrade. Deprecated or new feature changes should be done only after the upgrade release is completed.
One has to plan the sequence of software upgrade for ASP.Net solution and its components. For example, we undertook the changes in the following sequence:
- Convert ASP.Net 1.1 solution to ASP.Net 2.0 Web Application Project without Web Application Format change to pages.
- We upgraded Infragistics Controls using Upgrade utility provided by vendor
- Then we fixed all design time errors
- Then we fixed all runtime breaking changes
- Then we did changes for Enterprise Library version 3.1
- Then we started testing of application and then fixed all defects caught by testing team
As Database upgrade and ASP.Net upgrade are two completely different activities, this was done in parallel, and during the initial stage of upgrade we tested our code with SQL Server 2000.
Another aspect that may impact planning of upgrade is parallel development. We took a conscious decision to go ahead with parallel development of the upgrade and new enhancements. We took this decision considering following things:
- Most of the code in enhancement was new code which could be developed in new code files. There were not many changes to be done for maintenance.
- We did not convert our web page format to Web Application format so that the merging and comparing would be easy. If you choose Web Application project without web application format then usually only the project files get updated with all other files remaining as is.
- Only a few stored procedures needed modifications for the upgrade. This helped us to have working code with same database and two different ASP.Net versions.
- Sufficient time was allocated for merging after the code conversion.
Of course the decision should be taken with caution and impacts your planning and schedule. Extra precautions are needed for version controlling of source code.
2.1.4.2 Database Upgrade Strategy
The article Upgrading to SQL Server 2005 explains in detail how to upgrade to SQL Server 2005. This article has following sections:
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
- Setting compatibility level to SQL Server 2005
- Setting database options
- Setting row versioning feature
- 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:
- Necessary software installations like VSTS 2005, SQL Server 2005, Enterprise Library, Web Application project setup etc.
- Base lining of code for upgrade and creation of separate branch/folder in version control
- The execution of Wizard for upgrade will be done by single person and then the files should be distributed for design time breaking changes
- Fixing of design-time breaking changes are followed by fixes for runtime breaking changes
- Planning for configuration changes for deployment on development box
- Testing releases and test case planning
- Planning for defect fixing
- Planning for rollback and documentation of the corresponding strategy
- 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:
- 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
- Open each and every screen (.aspx/.ascx) in Design View.
- 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
- 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.
- 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.
- 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:
- Each defect should be considered independently and fix should be applied one by one as far as possible.
- Identify reason(s) for defect.
- 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.
- Enlist all the files and occurrences of defect in application. Locating all occurrences of a defect is important. 100% coverage should be targeted.
- Verify other occurrences for generic solution. Enlist occurrences which need a specific fix.
- Finalize the approach to be used to address the defect. Identify special cases for which a different fix is needed.
- Apply the fix for all occurrences.
- Conduct sanity testing.
- Check-in the code and send it forward for the next round of testing.
- 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:
- 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.
- 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.
- 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.
- 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.
- 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.