When to Migrate from Microsoft Access to Microsoft SQL Server

SQL Server Technical Article

Writers: Luke Chung and Dan Haught

Published: February 2005 Updated for Access 2007: October 2006 Applies To: SQL Server 2000 Service Pack 3a Summary: This paper explores the issues related to upsizing Microsoft Access applications to take advantage of the performance, security, and reliability of Microsoft SQL Server.

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

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

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

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

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred.

2004 Microsoft Corporation. All rights reserved.

Microsoft is either a registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

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

Contents
When to Migrate from Microsoft Access to Microsoft SQL Server ......................1 Executive Summary ...........................................................................................1 The Value of Access in Your Organization .........................................................1 Appropriate Access Usage: Building the Right Relationship Between Teams and IT 2 Access and the Jet Engine ................................................................................ 3 Access and SQL Server: a Quick Comparison ...................................................... 3 Topology Configurations ...................................................................................4 Access and Jet Single User ............................................................................... 4 Access and Jet Multiuser .................................................................................. 4 Access, Jet, and SQL Server ............................................................................. 5 Using Access and SQL Server Without Jet ........................................................... 5 Making the Decision: When to Upsize ................................................................6 Web Access .................................................................................................... 7 Scalability ...................................................................................................... 7 Maximum Database Size ............................................................................. 7 Number of Concurrent Users........................................................................ 8 Architectural Issues .................................................................................... 8 Reliability and Availability ................................................................................. 8 Database Corruption ................................................................................... 8 Backup and Maintenance ............................................................................. 9 Different Versions of Access and Jet ............................................................. 9 Security ......................................................................................................... 9 Access Application Limitations......................................................................... 10 Moving Away from Access .............................................................................. 10 Upsizing Scenarios ..........................................................................................11 Scenario 1: Already Right-Sized ...................................................................... 11 Scenario 2: Upsize Data Only ......................................................................... 12 Scenario 3: Upsize Application and Data Using Access ....................................... 12 Scenario 4: Upsize Application and Data Using Microsoft .NET Technologies ......... 13 Planning an Upsizing Project ...........................................................................14 Taking Inventory of Access Databases in Your Organization ................................ 14 Phase 1: Design and Planning ......................................................................... 15 Choose Your Upsizing Scenario .................................................................. 15 Identify a SQL Server Installation ............................................................... 15 Administration ......................................................................................... 15 Development Plan .................................................................................... 15 Evaluate the Microsoft Upsizing Wizard ....................................................... 15 Phase 2: Implementation ............................................................................... 16

Configure SQL Server ............................................................................... 16 Development ........................................................................................... 17 Testing ................................................................................................... 17 Documentation ........................................................................................ 17 Training .................................................................................................. 17 Rollout .................................................................................................... 17 Phase 3: Stabilization .................................................................................... 18 Conclusion.......................................................................................................18 Recommended Reading.................................................................................. 18

When to Migrate from Microsoft Access to Microsoft SQL Server

Executive Summary
This paper explores the issues related to upsizing Microsoft Access applications to take advantage of the performance, security, and reliability of Microsoft SQL Server. Topics discussed include: The Value of Access in Your Organization. A brief discussion of how Access provides power and agility to an organization's users. Access and SQL Data Architectures. A discussion of the type of data architectures that Access supports. Making the Decision: When to Upsize. An evaluation of the criteria to decide whether an application has outgrown the capabilities of Access. Upsizing Scenarios. An overview of the approaches to upsizing, and how to determine which one is best for you. Planning an Upsizing Project. An outline of what to plan for, to ensure a successful project.

The Value of Access in Your Organization

Inadequate or outdated data leads to poor decisions. Yet many information workers must effectively use an increasing amount of data in order to fulfill their roles. Information accumulates on desktops, file shares, Web sites, and within IT managed departmental and enterprise applications. IT professionals are challenged with how to manage data from disparate systems. As information workers try to use this information, justifiable friction may develop as they attempt to make better use of information to make decisions while IT departments work to manage security, reliability, and scalability on tighter budgets. The overall challenge for the organization is how to best empower information workers while meeting overall organizational needs. Microsoft Access targets individual information workers and small teams that use the Microsoft Office System to track, manage, prioritize, and act upon the increasing volume of business information. Its familiar Office environment enables workers to quickly build effective applications without requiring the skills of a professional developer. Information workers appreciate how easy it is to create applications that track issues, contacts, assets, events, projects, and other common types of team information tracking needs. Simple, fast, effective information tracking is a nearly ubiquitous need for teams of information workers, and much of this information is different and more local to that teams needs than the information contained in the organizations line of business applications. The information tracked may be ad-hoc and temporary, for a single limited project, or it may be used by a team on an ongoing basis. The design goal for Microsoft Access is to meet the need for simple, effective information tracking by end-users. IT organizations should work with teams to understand what tracking needs are appropriately met by local Access usage, and which are more appropriately met by more sophisticated IT-driven applications. Along with building tracking applications, information workers sometimes track data that is related to data in another system. To make informed business decisions, they often combine the data and create reports that illustrate trends. The lightweight ad-hoc query and reporting functionality in Access enables information workers to get needed information in line-of-business systems without burdening the IT organization.
1

When to Migrate from Microsoft Access to Microsoft SQL Server

Information workers use the friendly query and report wizards to join heterogeneous data to improve decision making by using accurate and up-to-date information. To meet the needs of information workers, Microsoft plans to continue to make development investments in Access that will yield improved ease of use and closer integration with the Office System and especially as a great companion tool to use with Windows SharePoint Services. SharePoint provides teams with the ability to create lists of information that are readily accessed and shared in the portal. SharePoint provides storage and easy access. Microsoft Access provides rich forms and reports for these lists. Information workers can use Microsoft Access 2003 to build forms and reports on team data through a Web services connection to lists in Windows SharePoint Services. Microsoft Access 2007 has built on this development work to make it easier than ever to create effective team tracking applications that provide information workers with new collaboration features. By encouraging the storage of information on SharePoint, IT also is able to better manage, administer, and back-up the tracked information.

Appropriate Access Usage: Building the Right Relationship Between Teams and IT
Most Access applications are created and used without any IT involvement. Microsoft estimates that 97 percent of all Access databases are used on a time-limited basis or continue to exist as an individual or small team application. This is appropriate in most cases, but in a small percentage of cases it would be more appropriate for IT to create a more sophisticated application. Consider the following scenario, which illustrates the need for good planning between a team and IT to determine the right usage plan. An information worker needs to create a small application to meet a new business need. When consulted, the IT manager tells the information worker the project will take three months and $50,000 to create the solution using professional development tools, and will be hard to schedule given the current demands on the IT department. The information worker is under a deadline and cannot wait that long, and does not have the budget to pay for the professional development. She builds the application in a week using Access and is able to effectively meet the immediate business need, which her manager praises her for. Coworkers are inspired by the new application and make requests to track additional information and provide modified reports. Because the application answers such critical business decisions, more and more people start using it. Over time the business need that inspired this application grows in importance to the company. Problems arise when the information worker finds that the application grows beyond her small team and becomes a departmental application now used by a much larger number of people, and has become critical for the operational effectiveness of the department. As the number of users increases, the network traffic increases and the performance of the application decreases. Then, the sole creator of the application accepts a new job in another division, at which point the manager calls IT for help in updating and maintaining the application. The application that was designed for an individual or small team has outgrown its original design. This scenario illustrates a challenge that information workers and IT organizations can face when the usage of an application grow far beyond its original intent. With an overgrown Access application, such as the one from this example, IT is often asked to help address the groups needs. In reviewing the application, an IT manager may find that the information worker did a poor job designing the schema -- numbers
2

When to Migrate from Microsoft Access to Microsoft SQL Server

and dates are stored as text and the data is not appropriately normalized. Also, the application design could use improvements, as forms and reports that pull all the data down locally cause network traffic overload. The IT manager is frustrated because he now has an unexpected new application to deal with, and must make significant improvements or migrate the application to core infrastructure platforms such as Microsoft SQL Server, which translates to the information workers as additional time and expense. Information workers and IT organizations can avoid the frustrations of an overgrown Access application. For applications that might expand into the department or across the enterprise, Microsoft recommends that information workers collaborate early during the development phase to head off future problems, especially on schema design. If needed, the data can be easily moved at a later date. Additionally, the migration to SQL Server is significantly easier if an IT professional ensures that data typing is done correctly, the data is properly normalized, and that base queries enable the information worker to create the right reports.

Access and the Development Environment:

Versions of Access prior to Access 2007 had there own database enginethe Microsoft Jet database engine. Jet is designed as a file share database that supports single and multiuser database applications with databases up to 2 gigabytes (GB) in size. Access is more than a database engine. It is a development environment that allows users to design queries, create forms and reports, and write macros and Visual Basic code to automate the overall application. In its default configuration, early versions of Access used Jet internally to store its design objects such as forms, reports, macros, and code, and also uses Jet to store all table data. Access 2007 no longer distributes the Jet engine with the latest Microsoft Data Access Components (MDAC). One of the key benefits of Access when upsizing is that you can redesign your application to continue to use the forms, reports, macros, and code you have already designed in Access, and replace the Jet engine with SQL Server for your data storage. This allows the ease of use of Access, with the reliability and security of SQL Server.

Access and SQL Server: a Quick Comparison

To understand the decision points in the upsizing decision process, consider the following Microsoft recommendations on appropriate usage on Access compared to SQL Server: Access Description Database development environment that supports tables, queries, forms, reports, and programming logic. 2 gigabytes (GB) Up to 20 concurrent editors. Up to 100 concurrent SQL Server Scalable, reliable, and more secure client/server database engine.

Maximum database size Maximum concurrent users

1 terabyte or greater Unlimited

When to Migrate from Microsoft Access to Microsoft SQL Server

reports being run. Security Performance Reliability File access-based security. Limited by file share model. Adequate for individuals and small team usage. Recovery from network failures cannot be rolled back. Enterprise-level security. Limited only by hardware and application design. High reliability. SQL Server is a mission-critical database. Backup and administration tools available.

Microsoft acknowledges that many customers exceed the maximum concurrent users guidelines given above. The Access database engine supports up to 255 concurrent users but the performance of the application depends on the design of the application. Proceed with caution if your application exceeds the recommended guidelines shown above.

Topology Configurations
There are a number of different topology configurations that leverage the power of Access and SQL Server.

Access and Jet Single User

Prior to Access 2007, versions of Access used the Microsoft Jet database engine to store both object definitions and table data. Access and Jet are run on the user's computer, and the database is stored on a local hard disk, as shown in the following figure.

Access and Multiuser Access

Access and its database engine allow multiuser access. In this scenario, each user runs a local copy of Access and Jet, and points to a shared database on a network drive, as shown in the following figure.

When to Migrate from Microsoft Access to Microsoft SQL Server

Access, Jet, MDAC, and SQL Server

Access also allows you to point to SQL Server for your data storage. In this scenario, Access is using Jet to run queries, store object definitions, manage temporary tables, and hold security settings. However, all table data is stored in SQL Server, as shown in the following figure.

Using Access and SQL Server Without Jet

Access data projects (adp) introduced in Access 2000 are front-end applications that bypass the database engine. Access 2000 and later versions have the capability to directly connect to SQL Server without the need for the database engine, as shown in the following figure.

When to Migrate from Microsoft Access to Microsoft SQL Server

Making the Decision: When to Upsize

Now that you have reviewed the various architectures and database engine options, you will want to explore the decision points and parameters for making the upsizing decision. The most important part in this process is to recognize that not all Access databases need to be upsized. A majority of Access applications should not be upsized because the cost and disruption to business is not a cost-effective use of resources. These databases work on a day-to-day basis, and do not need attributes such as scalability, security, and 100 percent reliability. For most organizations, only a small percentage of Access databases are candidates for upsizing. Additionally, from the list of candidates for upsizing, a majority can be upsized using a cost-effective process where only the data is moved to SQL Server. All of the application's functionality in terms of forms and reports is kept in Access. Also, only the smallest percentage of upsizing projects that grow to service departmental and enterprise scenarios requires rewriting the Access application in a new environment such as .NET. In general, these projects justify the expense of conversion because features beyond the capabilities of Access are required, and a business opportunity exists. The following figure shows the upsizing opportunities.

When to Migrate from Microsoft Access to Microsoft SQL Server

The following sections examine each of the key areas involved in database planning, and discuss how Access performs in each area.

Web Access
One of the most common reasons for migrating Access data to SQL Server is the need for the data to be available in the browser either through Internet or Intranet connections. Knowledge workers want to provide colleagues access to their tracking information, and often the Web is the most accessible place for others to find that information. When the data is moved to SQL Server, knowledge workers can still connect to it through link tables, but IT professionals can begin to build custom ASP.NET Web forms and SQL Server reports for parts of the application that need broader visibility inside the organization.

Scalability
Scalability is defined as the capability of an application to operate in an acceptable manner as the number of users or processes calling the application increases. Access, with the Jet database engine, is not a scalable solution, and scalability is often the primary motivation for upsizing.

Maximum Database Size

Access can support up to 2 GB of data. However, in many cases, this limit is theoretical rather than practical: Access uses the file share-based Jet database engine. Unlike client/server solutions such as Microsoft SQL Server, file share databases are not optimized for large datasets. For example, an Access query that needs to provide a total of 10,000 orders needs to pull all 10,000 orders across the network, do the computations locally, and then provide the total. In the client/server model, the same query is handled directly by the server, and only the result is returned to the client application. With larger database sizes, the file share architecture is not capable of handling data loads. Access database engine is not designed for optimum or reliable performance with large database sizes. A few installations will have data corruption because of poor network connectivity or incorrectly designed applications.

When to Migrate from Microsoft Access to Microsoft SQL Server

Number of Concurrent Users

Microsoft Access can technically allow 255 connections for each database. However, this is a theoretical limit and cannot be attained in an organization. In reality, the number of connections or users that an Access database can support is dictated by how well the application was designed and implemented. For example, a professionally designed and well-tuned Access application can support up to 20 concurrent users who are updating data with good performance. Databases that are used largely for running read-only reports can scale up to about 100 users. Unfortunately, few Access databases are well-designed and implemented with best practices. This is because most Access databases are created by beginners or power users who do not have the experience or knowledge to create professional applications. They are built over time, and new features and data models are added as needed. The result is that many solutions dont reliably support more than a few users.

Architectural Issues
Because Access uses Jet or MDAC for database management, it cannot scale well by definition. Jet is limited to run on a single CPU, whereas client/server solutions such as Microsoft SQL Server can support multiple CPUs. Additionally, Jet queries always run on the client computer, which eliminates the centralized query or data optimization necessary for a scalable solution.

Reliability and Availability

Reliability is one of the key benchmarks to consider when upsizing. For many critical applications, reliability is the single most important consideration. This includes avoiding Jet database corruption and having data backups. Microsoft Access is not intended as an inherently reliable solution for several reasons.

Database Corruption
When early versions of Microsoft Access databases (using the Jet engine) encounter an error or connection problem, the database may become corrupt. A corrupt database generally locks out all users of the database, and generally results in business disruption and infrequent data loss. Microsoft Access databases (using the Jet engine) are susceptible to corruption for a number of reasons. Because Access uses a file share model, all users are concurrently holding active connections to data. If any one of those users unexpectedly loses the connection during a data update process, the database may become corrupt. Microsoft Access includes a Compact/Repair tool, but data corruption cannot always be fixed by this tool. Third-party repair services are available, but this requires sending the affected database to another location, paying a fee, and waiting for it to be returned. Even though you experience Access database corruption, you may not need to migrate to SQL Server. Access databases need to be periodically repaired and compacted to maintain efficiency, avoid corruption, and minimize expansion. Databases that are not periodically compacted may suffer corruption, but those which are properly managed often run reliably. FMS offers a product, Total Visual Agent (http://www.fmsinc.com/products/agent/), that lets you schedule database compaction and backups for all your Access databases across your network, to ensure they remain
8

When to Migrate from Microsoft Access to Microsoft SQL Server

healthy. Many organizations run this on a nightly basis. Unfortunately, databases that run 24 hours a day and seven days a week do not allow Jet to have an exclusive lock to perform the compaction, and these situations demand moving to SQL Server.

Backup and Maintenance

Because Access uses the file share model, the entire database is locked at the file level as soon as the first user accesses it. This means that no reliable mechanisms exist for performing backups of the database file unless all users are disconnected. In a multiuser environment, it is often difficult to coordinate the process of ensuring that all users log off an Access application before making a backup. Typical scenarios involve users leaving their computers on when they leave the office for the day. This leaves the database open, and backup software will not be able to reliably copy the database file. Often, this is only detected after the backup fails, leaving the system administrator to track down the problem and hope it is resolved before the next backup runs. Additionally, Microsoft Access is not self-tuning. It does not automatically reclaim lost database space, or optimize indexes and queries. This maintenance can be performed by running the Compact/Repair tool, but this also requires that all users be logged off the database. Additionally, many Access databases are stored locally on a user's computer, and they are often not included in any type of backup or maintenance plan.

Different Versions of Access and Jet

Microsoft Access has strong dependencies on specific versions of the Jet engine, and other related data access components. For example, if you create a database with Access 97, it can be opened with Access 2000, which can convert it to make it unavailable to Access 97 users. Additionally, if new versions of standard Microsoft data access components, such as Data Access Object (DAO) and ActiveX Data Object (ADO) are installed, they may make existing Access applications fail. This is especially true in multiuser situations. This lack of backward compatibility can cause organizations to hesitate in upgrading to newer versions of Office, because a new version of Access can cause existing Access applications to fail. So far, the version issues are focused on Access at the application level. The same issues arise if Access is the front end to a SQL Server back-end database. It's also important to note situations where Access databases are used by programs other than Access. Many Visual Basic applications use Jet for their database storage, and programs written in C++ may also use Jet. Before migrating a database from Access to SQL Server, it's critical to know all the applications that use it.

Security
The most reliable mechanism to secure Access databases is to set Microsoft Windows network file systems permissions on the file or folder. In addition, Microsoft Access offers three different obscurity mechanisms that attempt to hide information from users of the application:

When to Migrate from Microsoft Access to Microsoft SQL Server

Database passwords. You can assign a password to a database. Only users who know the password can open the database file. In Access 2007 the security model is stronger. Including improved encryption of database passwords, and user level security. File encoding. Contents of the database can be encoded at the file level.

Unfortunately, these mechanisms are designed for usability and not for securing the file. Access is built on a file-based database engine, which requires read permissions to the actual database file. Therefore, users will be able to copy the file using the Windows shell and use custom tools to modify the binary representation of the file directly, thereby getting around all Access-specific security mechanisms.

Access Application Limitations

As an Access application expands into large departmental and enterprise scenarios there comes a growing need to rewrite the application. Generally, the application evolves over many years and with many developers, updates and workarounds are implemented. It may be time for a complete system redesign, to fix architectural problems and to implement new features that were too disruptive in the existing structure. This can be done in Access, but it's an opportunity to invest in a new platform that exists on SQL Server and can support the future needs of the organization beyond the capabilities of Access.

Moving Away from Access

Many IT and business people are frustrated by the proliferation of Access databases that now need upsizing. Access should not be blamed for the situation, because these Access databases were created by people to solve their business needs. In most cases, their needs were minimal and did not justify professional database development by the IT department. IT departments may not have time to handle all the database needs of end users. However, as time passes, business changes, opportunities arise where simple database solutions became more important, and some Access databases become critical. This is a trend that will continue. It is impossible to predict which among the hundreds of databases that are created every year will become critical several years later, when others disappear. Initially, the expense of building a robust, SQL Server application could not be justified. The process of business and database evolution culminates with a few applications that require additional investment today. IT department personnel and professional developers should appreciate the role Access users and developers have in providing solutions that become candidates for upsizing. These applications can be upsized successfully, with appreciative end users and managers, who can now justify the additional investment that could not be justified earlier.

10

When to Migrate from Microsoft Access to Microsoft SQL Server

11

Database Design Considerations

Access databases are typically created by the end user with little knowledge of database design skills. When considered upsizing an Access database, one should als address the likelyhood that a poorly designed end user database that was suited for small teams, will have problems and issues when upgraded to SQL Server for addressing a different new scaled out scenario. The database most probably must be re-designed for the new scaled out scenario. Particulalry the design of tables queries should be closely evaluated. These steps will help transition the Access database more smoothly and address any poorly designed database issues.

Upsizing Scenarios
When contemplating an Access upsizing project, there are a variety of upsizing methodologies. These range from simple data moving, to complete rearchitecture and redesign. To choose the correct path for your upsizing project, you should be familiar with the three types of data architecture that Access supports. This section outlines upsizing scenarios and provides details about the benefits and drawbacks of each approach. The following scenarios are examined. Scenario Description Percentage of existing databases 90 percent 7 percent 3 percent

Already Right-Sized Upsize Data Only Upsize Application and Data Using .NET Technologies

Many Access databases do not need to be upsized. Leave application design and logic in Access, and move data to SQL Server. Rewrite the application using Visual Studio .NET for Windows or Web access, and move data to SQL Server.

Scenario 1: Already Right-Sized

The first rule of upsizing is that the majority of your databases should not be upsized, because the cost is prohibitive. Even if you have the resources to upsize a majority of your Access databases, there may be no real benefit. Simple lists or reports used by a single person typically are not critical applications. These types of applications are what Access is designed for, and are well within its capabilities. Access (using the Jet database engine) cannot scale and does not have the reliability and security of SQL Server. However, that is typically not an issue for the majority of your Access databases. The key advantage to this approach is that you don't have to take action for individual and small team databases, or for older databases that can realize cost savings in hard disk space. The following table shows the advantages and disadvantages of Scenario 1: Already Right-Sized. Advantages Disadvantages Limited scalability Limited security

No additional software needed, because Jet or MDAC is included with

When to Migrate from Microsoft Access to Microsoft SQL Server

Access No SQL Server knowledge required Lowest development costs

Limited number of users Limited reliability Possible failure, if new versions of Office, Access, Jet, or data access components installed

Scenario 2: Upsize Data Only

Because Access can link to SQL Server for table data, migrating only the data is one of the best balances between cost and benefits. In this scenario, you move all table data to SQL Server and leave all forms, reports, queries, macros, and logic in the existing Access database. This scenario is the quickest and most cost-effective, because it has the least impact on existing application logic. Very few, if any, parts of the existing application need to be changed. With a small investment, you can gain the reliability and maintenance benefits of SQL Server and keep your Access investment. After the data is in SQL Server, it is possible to begin re-writing portions with a more robust environment such as Microsoft Visual Studio .NET and SQL Server Reporting Services. This process of moving an Access application towards more scalable and robust platforms is referred to as upsizing. Scenario 2: Upsize Data Only is best for Access applications with a small number of users and small database sizes. The following table shows the advantages and disadvantages of Scenario 2: Upsize Data Only. Advantages Lowest cost upsizing project Data located in SQL Server, offering security, scalability, and reliability Disadvantages Business users cannot modify schema to track new information Lacks access to SQL Server scalability features such as stored procedures, functions, and so forth Possible failure, if new versions of Office, Access, Jet, or data access components installed

Scenario 3: Upsize Application and Data Using Access

If you are planning to upsize an Access application, and performance and scalability are as important as other benefits (such as reliability, security, and maintenance), you may want to consider not only moving to SQL Server for your data, but rewriting your Access application to remove the Jet engine. You can do this by using the Access Data Project format that is available in Access 2000 and later. Access Data Projects allow the same forms, reports, macros, code, and intuitive design tools available in standard Access databases. However, they directly connect to SQL Server for data access. There are two situations where you would consider this scenario:

12

When to Migrate from Microsoft Access to Microsoft SQL Server

13

An existing Access application is using Jet only and needs to be upsized to SQL Server in a way that offers optimum performance and scalability. An existing Access application is connected to SQL Server through Jet and needs better performance and fewer SQL Server connections.

The major benefit of this scenario is that it results in an Access application that provides the best performance and scalability, as well as the other positive attributes of SQL Server. The major drawback to this approach is that it requires more development effort, because Access objects such as forms, reports, queries, and code need to be redesigned to work directly with SQL Server. The following table shows the advantages and disadvantages of Scenario 3: Upsize Application and Data Using Access. Advantages Benefits of SQL Server, including performance and scalability Data located in SQL Server, offering security and reliability Disadvantages Cost of redesigning application logic and retesting, offset by the improvements gained

Scenario 4: Upsize Application and Data Using Microsoft .NET Technologies

When an existing Access application outgrows Access, it can do so in a major way. Access is no longer able to keep up with your organization's requirements of scalability, reliability, and performance. Or, you may need to migrate all or part of an application to the Web. A small percentage of Access upsizing projects can only successfully be completed by migrating from Access. In this scenario, the Access application is used as the beginning for a new design. Additional technologies such as Visual Basic, Active Server Pages (ASP), and Visual Studio .NET are used to rewrite the application. As part of this process, the data moves to SQL Server. Additionally, you can consider migrating other data sources, such as Oracle and DB2 into SQL Server for a centrally managed solution. The advantage of this approach is flexibility. You can create an application that can target computers running Windows and the Web with minimum changes. A more professional development environment, such as Visual Studio .NET, offers advantages such as team-based management, source code control, and professional tools and components available from third-party vendors. With this scenario, you will have a reliable, scalable, and manageable application that can move from the business unit to the enterprise level. The disadvantage of this approach is cost. Because you are discarding the Access application and its database, you are creating a new application with a new design, development, and implementation project. Fortunately, only a small minority of Access applications require this level of effort. The following table shows the advantages and disadvantages of Scenario 4: Upsize Application and Data Using .NET Technologies. Advantages Flexibility, because application can target Windows, Web, and more Disadvantages Highest cost Retraining of staff

When to Migrate from Microsoft Access to Microsoft SQL Server

Scalability and reliability, using .NET development technologies with SQL Server for the best midlevel and enterprise level return on investment Ease of management, because versions of Access no longer have any role in the application's capability (or incapability) to be used across the enterprise

New application testing Additional developer expertise

Planning an Upsizing Project

To avoid unnecessary costs, ensure application availability, and minimize risks, you should carefully plan your Access upsizing project. The amount of planning is directly related to the type of upsizing project you envision. For example, a simple migration of data to SQL Server requires less planning than a complete rewrite of the application and data migration. The following sections provide guidelines and best practices for planning your upsizing project.

Taking Inventory of Access Databases in Your Organization

One of the challenges for your organization is identifying how many Access databases you have, and which ones should be upsized. The problem is where to start. How do you efficiently inventory your Access databases to get an initial understanding of the problem? Even with conservative estimates, an organization with 500 client computers may potentially have 10,000 Access databases. You have several strategies for solving this problem. The simplest route is to communicate with users, usually through an e-mail message, and ask for basic feedback on each user's database inventory, such as: How many Access databases do you currently use? How many tables are in these databases? Do you share this database with other users? Do you link to, or use import/export on, corporate data? Are your databases being backed up? Are there other applications that use the database? (For example, an application may be shared by front ends in Access, Visual Basic, or C++.)

A well-defined (and brief) set of questions will help you identify which databases may be at risk. For larger organizations, a better-managed approach is to implement a system that can automatically inventory and report on Access databases. A desktop agent that regularly inventories local and network hard disk drives, in combination with a centralized server reporting application, can provide tangible benefits for an organization's need to manage user data, and schedule upsizing projects. Microsoft supplies the Access 2003 Conversion Toolkit for pre-Access 2007 versions and the Office Migration Planning Manager OMPM handles this for Access 2007 to help you with the process of finding and classifying your Access databases.
14

When to Migrate from Microsoft Access to Microsoft SQL Server

15

Phase 1: Design and Planning Choose Your Upsizing Scenario

Your level of planning and overall effort is directly related to which upsizing scenario you choose. For example, upsizing data to SQL Server while leaving the Access front end in place requires less effort, but yields fewer benefits. After you have chosen your plan, be sure to clearly state goals, timeline, and budget.

Identify a SQL Server Installation

After you choose to upsize an Access application, you will need to either identify an existing SQL Server installation to use, or plan to create one. SQL Server comes in a variety of editions, from the freely available Microsoft Database Engine (MSDE) to SQL Server Enterprise Edition. In general, all editions of SQL Server, including MSDE, are capable of handling small workgroup applications involving 120 users. If you are upsizing both the application and the database, and your needs call for the greatest scalability, functionality, and reliability, consider using the Enterprise Edition.

Administration
Before your upsizing project is deployed, you should have an administrative plan for your new SQL Server data. Planning for this before the rollout is key. Installing SQL Server and creating objects are only part of the plan. You should define backup schedules, fault tolerance parameters (as needed), and administrative staff who are responsible for the database component.

Development Plan
Create a development plan that covers each aspect of the Access application that must be changed. If you are only planning to upsize the data to SQL Server, parts of the Access front end may still need to change. For example, the Jet database engine uses different data types, and a different SQL grammar than does SQL Server. Plan to identify any areas of incompatibility and change Access objects as needed. If your scenario calls for a complete rewrite of the Access application in a different environment, such as .NET, you need to approach the project as a full life cycle software development effort and plan accordingly. Finally, be sure to identify risk areas, such as data destabilization or loss that could potentially occur, and have a proactive plan in place to address them. In rare cases, other applications may share the Access database. This can include other Access databases and applications written in Visual Basic or C++, and sometimes even low-volume Web applications. All of these platforms will need to change when the data migrates to SQL Server.

Evaluate the Microsoft Upsizing Wizard

Microsoft provides an upsizing wizard that allows semiautomatic upsizing of Access to SQL Server. This wizard is limited in its capability to create usable SQL Server-based applications. When you are contemplating an upsizing project, you can use the Microsoft Upsizing Wizard as a starting point. However, except for the most simple upsizing projects (for example, Scenario 2: Upsize Data Only), the Microsoft Upsizing

When to Migrate from Microsoft Access to Microsoft SQL Server

Wizard will accomplish only about 40 percent of the work. The following table describes the limitations you may encounter with the Microsoft Upsizing Wizard. Issue Nonstandard table or field names Differences in SQL Data type conversion issues Description Access and SQL use different naming standards. The Upsizing Wizard can find some, but not all. Those that it does find and rename will not work in any existing code. Access uses its own dialect of SQL that is different from the ANSI SQL supported by SQL Server. Many Jet-based queries cannot run on SQL Server without being rewritten. Access has its own standards for data types that are different in some cases from SQL Server. The Upsizing Wizard can make some choices for you in terms of converting data types, but changes require developer review. Attachment data types and multi-valued fields in Access 2007 will not translate to SQL Server. The Upsizing Wizard cannot rewrite your application to work correctly with the SQL Server client/server model. Almost all Access applications are designed to work with the file share model of Jet. These designs do not lend themselves to the client/server model and can result in poor performance. The Upsizing Wizard does not convert any of the Visual Basic for Applications code in your application. This can result in serious errors as parts of your application point to SQL Server while your code still points to an Access database. The Upsizing Wizard does not convert any of the following objects: hidden objects, security settings, Format and InputMask properties, Table or Field caption properties, table lookup fields, crosstab queries, action queries that use parameters, many query properties, macros, and module code.

Architectural issues

Code not converted

Items not upsized

In general, consider using the Microsoft Upsizing Wizard as a starting point, or for proof-of-concept phases. However, it cannot be relied on to completely upsize an application in the correct way.

Phase 2: Implementation Configure SQL Server

Use the data diagram that is part of your development plan to implement the first version of SQL Server objects, such as tables, views, and stored procedures. Implement users, groups, and roles as needed. It is important to have these objects in place before development starts, because developers can't work against a SQL Server back end that isn't there. Don't worry about performance optimization yet, because that happens later.

16

When to Migrate from Microsoft Access to Microsoft SQL Server

17

Development
Based on your development plan, staff your development team and provide the resources necessary. Make the existing Access and other applications dependent on the data available to the team for use as a benchmark or prototype resource. Monitor the milestones and risk areas defined in your planning process.

Testing
Before the first test deployment of the new application, basic developer-based testing should occur. Use the existing Access application as a model to reduce the amount of time needed for the initial testing effort. Compare each functional area in the original Access application against the new code base. If you are completely rewriting the Access front-end application as well as moving the data, you should plan to involve dedicated quality assurance or testing staff to find critical errors.

Documentation
Most Access applications are created by end users, and lack documentation. Because you are investing in the process of upsizing, this is the time to document the new application. At a minimum, create a configuration and troubleshooting document that outlines where the application's component parts reside, desktop and network settings, and basic troubleshooting techniques based on the results of your testing plan. If you have the resources, you may consider more complete documentation, such as data diagrams, flowcharts, and code listings.

Training
When you take an existing in-production application and change or rewrite it, you must ensure that the application's users are informed. Depending on the scope of the changes in the upsizing project, training for the application's users may range from a few hours of walk-through training to full formal training with the associated training guides and documentation. Training is crucial if you want the cooperation of the application's users.

Rollout
Your first rollout of the application is typically deployed to a subset of the entire user population. Select a small group of users and employ them as the beta testers. The goal is to verify the planning and development work. Does the new application work correctly? Also, user feedback may help identify any last minute issues not addressed in the planning and implementation process. Users can also provide invaluable information regarding usability. After you have been through initial testing, and made any necessary changes or fixes, roll the application out to the entire user base. Depending on the number of users in the application, and the importance and currency of the data, you may want to consider running the old Access-based system in tandem with the new system for a period of time. This provides an extra degree of security should the new application experience problems.

When to Migrate from Microsoft Access to Microsoft SQL Server

Phase 3: Stabilization
After the new application is in production use for all users, the project enters the stabilization period. Defects are identified by users and fixes are planned. Users will also see opportunities for new functionality (as is the case with any application) and these should be noted by management. Ongoing support to users is important because an upsizing project often results in application attributes that are no longer under the control of the end user (for example, when using SQL Server). During this period, you should also monitor performance, not only in terms of what users may be reporting as slow, but active monitoring of SQL Server using tools such as the query analyzer and performance counters.

Conclusion
This paper provides an overview of the Microsoft Access to Microsoft SQL Server upsizing process and how to evaluate databases for upsizing. Fortunately, for most organizations, only a fraction of their many Access databases are candidates for upsizing. By optimizing the use of Access, even fewer databases may need to migrate. The remaining candidates for upsizing require the evaluation of the IT and business needs for each application. From a simple back-end database switch with minimal frontend modifications to a complete application rewrite, several alternatives are available for upsizing, depending on the features required, available resources, and what you want to preserve from the existing application. Approach these situations as opportunities, and anticipate that more opportunities will exist in the future, as database computing becomes even more powerful. You can deliver the full power of SQL Server to business units that can justify the investment and appreciate the results.

Recommended Reading
For more information about Access, SQL Server, and upsizing, please see: Access in the Enterprise: http://www.fmsinc.com/upsize/ When to upsize a Microsoft Access database to Microsoft SQL Server: http://msdn.microsoft.com/library/default.asp?url=/library/enus/off2000/html/acconWhenToUpsizeMDBtoSQLServer.asp

18