Deployment Guide
Migration Service for SQL Server 2012 (Oracle)
Prepared for
Customer Name
December 2012
Version Released
Prepared by
<Insert Author Here - File Properties>
Author Position
authorEmail@partner.com
Contributors
Page 1
[Document Contributors]
Page 2
Table of Contents
Purpose .............................................................................................................................................5
Audience ...........................................................................................................................................8
Deployment .......................................................................................................................................9
Deploying the Database Server..................................................................................................................... 9
Process ................................................................................................................................................... 9
Technology........................................................................................................................................... 11
Automated Deployment ...................................................................................................................... 11
Deploying the Server Side Applications ...................................................................................................... 12
Process ................................................................................................................................................. 12
Technology........................................................................................................................................... 12
Deploying the Client Application ................................................................................................................ 12
Process ................................................................................................................................................. 13
Technology........................................................................................................................................... 13
Change Management .......................................................................................................................... 14
Stabilizing the deployment ......................................................................................................................... 15
Deployment Checklist .......................................................................................................................... 15
Server ................................................................................................................................................... 15
Database .............................................................................................................................................. 16
Application (Client Side or Server Side) ............................................................................................... 17
Additional Considerations ................................................................................................................... 18
Quiet Period ......................................................................................................................................... 18
Transferring Ownership to Operations ....................................................................................................... 19
Project Team Tasks .............................................................................................................................. 19
Operations Team Tasks........................................................................................................................ 19
Page 3
Conclusion ....................................................................................................................................... 21
Page 4
PURPOSE
This document provides a direction towards the deployment of Migration from Oracle Environment to a
SQL Server 2012 Environment.
After envisioning, planning, developing, and stabilizing, the solution is ready to be deployed. The
Deployment Phase implements the tested solution in the production environment. The migration
project release management team deploying the solution works with the operations team to
successfully deploy and stabilize the solution. At the close of the Deployment Phase, customer approval
for the migration is obtained, and the solution is transferred to the operations team. It is also possible
that the operations team handles the deployment with the aid of the project team. Irrespective of which
team does the deployment, the key goal of the Deployment Phase is to successfully migrate the new
solution into the production environment as smoothly as possible, and with the least amount of
disruption to the business environment or the end users.
The deployment rollout should be conducted as a series of activities. Though you can abbreviate or
combine some of these activities, you cannot skip any of them completely without increasing risk to the
project's success.
Nearly all of these activities are performed in conjunction between the project team and the operations
team. Coordination between the two teams is now a critical success factor. All decisions should be
agreed upon by both of the teams to minimize risk. Both teams are involved with completing the tasks
and producing the deliverables:
Major Tasks and Deliverables for the Deployment Phase
Tasks
Deliverables
Roles
Checklist1
Deploy the solution
Deployment
Release Management
Stabilize the deployment
Deployment Checklist
Release Management
Obtain the solution signoff
Customer Sign Off
Product Management
Transfer ownership
Project Documents
Program Management
The Major Tasks and Deliverables of a typical Oracle migration projects are:
Tasks
Deliverables
Migrate the Oracle database architecture
SQL Server instance equivalent in structure to
the source
Migrate the schemas
SQL Server databases housing application
schemas
1
Deployment checklist is typically a spreadsheet or document identifying all the objects by topic (Instance(s), schema(s), tables, views,
procedures, functions, et cetera).
Page 5
Migrate the users
SQL Server users with similar privileges as the
source
Migrate the data
Complete database ready for use
Because they are both relational databases, Oracle and SQL Server have some similarities, but also
have some differences in their features and functions. Both Oracle and SQL Server provide all the core
functionality expected of a RDBMS, including concurrency, security, backup, recovery, scalability,
availability, session management, transaction management, storage management, resource
management, and so on. Both exhibit a moderate degree of compliance to ANSI standards.
Migrating from Oracle to SQL Server poses less of a challenge than migrating from one proprietary
computing system to another. SQL Server is a relational database just like Oracle and, hence, it is not
necessary to redesign the database. It is not necessary to re-architect the application for performance
or security because the two DBMS are different in their architecture. The majority of the work
involved is in accommodating the differences in the implementation of items such as indexes, data
types, SQL syntax, and specific DBMS features, such as physical/logical disk storage considerations,
partitioning, and auditing.
To simplify the migration of the database, the entire process has been organized into four major tasks:
Migrate the Architecture
Migrate the Schema
Migrate the Users
Migrate the Data
Each of the four major tasks includes a set of subtasks:
1.
Migrate the database architecture
1.
Build the SQL Server instance
2.
Configure the server
Page 6
2.
3.
4.
3.
Migrate the storage architecture
Migrate the schemas
1.
Create database for the schema
2.
Create a user for the schema
3.
Create the schema objects
Migrate the users
1.
Create logins
2.
Create roles and grant privileges
Migrate the data
1.
Plan the data migration
2.
Execute the data migration
Page 7
AUDIENCE
The primary audience for this document are delivery consultants. The secondary audience includes
Field Stakeholders and the Roles & Readiness team. Through the development of the document, the
team must verify as completely as possible that everyone has a clear and consistent understanding
regarding the content of the document and therefore the direction for the project.
Page 8
DEPLOYMENT
Once the application and the database have been migrated the database and applications (server side
and client side) are fully tested and are ready for deployment. The release versions of the source code,
executable, scripts, and other installation information are complete and delivered to the deployment
team.
While deployment is often discussed and planned singularly, there are actually three separate
components and technologies that must be deployed into the production environment. These solution
components are:
●
Database servers
●
Server side application(s)
●
Client side application(s)
Each of these components is discussed in this section. Each of these topics is divided into two subtopics:
process and technology.
Deploying the Database Server
The database should be deployed first because the server side and client side applications are
dependent on it. The process and technology required for setting up a database server and
implementing databases are discussed under the following headings.
Process
During the Planning Phase of the migration, all hardware needs are evaluated and any new equipment is
acquired. During the Deployment Phase, the server must be set up and configured for the Windows
Server 2008 or 2012 environment. The following procedure describes the steps for deploying the
database and its server:
1. The server should be built and delivered by your hardware vendor based on specifications
defined during the Planning Phase. If the server will be built from existing equipment,
ensure that the server is available and has the required capacity to host the solution.
2. Install any necessary hardware. Commonly, items such as additional memory, interface
cards, additional storage, tape drives, or FDDA gigabit switches will need to be installed to
meet operational specifications.
3. Install the operating system, including any necessary service packs and patches. This step
can be performed manually or by using imaging software. This topic is discussed in greater
detail in the technology portion of this section.
4. Configure any additional hardware that was installed. For instance, if NIC cards are
installed, they must be configured to match the settings of the network switch they will
connect to.
Page 9
5. Install any additional applications needed for the server, such as monitoring applications,
backup software, asset management software, and software delivery applications.
6. Select the deployment mechanism for the database. Some possible options include:
●
Use automated processes, such as installation and configuration scripts, where
possible.
●
Use manual processes for some installation and configuration. These must have
detailed, step-by-step instructions.
7. Create the database deployment package by putting together the following:
●
SQL Server installation and configuration scripts.
●
Database administration tools and utilities.
●
Database administration scripts and a scripting language such as Perl.
●
User database migration scripts.
●
Database administration tasks and packages, such as a maintenance plan, jobs, and
backup and restore procedures.
●
Windows domain user accounts configuration scripts.
●
Scripts for configuring ODBC data sources, ADO, and OLE DB connection strings.
●
Scripts for configuring COM+ components for database connection.
8. Create rollback scripts to undo or remove changes introduced by the deployment. If a
parallel cutover strategy is being employed, the scripts should disable the replication. Not
every aspect of the fallback can be scripted. A checklist of tasks with detailed instructions
should be prepared.
9. Add the deployment package to the configuration management database (CMDB).
Maintain change control of the release. Where a CMDB does not exist, a simplified one
should be created for release-tracking. The purpose of updating the CMDB is to ensure
that accurate knowledge is stored regarding all of the components or configuration items
that make up the releases.
10. Execute deployment package for the databases being migrated as per the phase-out
strategy.
11. Execute the scripts to create the database and its objects. The serial cutover strategy will
dictate the order in which the databases are migrated.
12. If a straight cutover strategy is used, shut down the Oracle databases. If a parallel cutover
is used, the databases may not be shut down. However, a quiet period is required to
enable the replication and ensure that the replication mechanism is working properly.
Start migrating the data.
13. Monitor the data migration for errors. If the migration has to be aborted, the rollback
scripts and other fallback steps should be performed for each of the databases impacted
by the failure (if the databases are related and have to be migrated together).
Note: If you must deviate from these scripts in the production environment, make sure to
alter the scripts to reflect the change and enter a note in the script or documentation
regarding what was altered, why, and whether you noticed any issues afterward.
Page 10
Technology
Setting up and configuring servers can be time-consuming, especially if additional applications are
needed for operations, monitoring, reporting, or other purposes. Based on the needs of the
deployment, there are two ways to deploy the server; manual deployment or automated deployment
using imaging tools. Imaging tools allow for applications, operating systems, configurations, or drivers to
be installed in one package, instead of as individual installations. However, imaging can only be useful
when setting up identical servers using identical hardware, as in a clustered set.
The following link provides information on Windows Server 2012 and Windows Server 2008 R2:
http://technet.microsoft.com/en-us/library/hh801901.aspx
Manual Deployment
If a manual deployment is a consideration, a few guidelines should be noted. Often, hardware vendors
will provide customized installation CDs that contain specific drivers and software needed for the
configuration. Using these installation discs can reduce the time needed for installation.
Windows Deployment Services is the updated and redesigned version of Remote Installation Services
(RIS). Windows Deployment Services enables you to deploy Windows operating systems over the
network, which means that you do not have to install each operating system directly from a CD or DVD,
refer to:
http://technet.microsoft.com/en-us/library/jj648426.aspxCreation of the databases and database
objects can be performed using Data Definition or even through SSIS packages.
Automated Deployment
There are several ways to deploy Windows Server, depending on the version. Refer to the following for
guidance:
Windows Server 2012:
http://technet.microsoft.com/en-us/library/hh831620.aspx
Deployment Toolkit: http://technet.microsoft.com/enus/solutionaccelerators/dd407791.aspx
System Center:
Windows Server 2008:
http://technet.microsoft.com/library/ee344846(WS.10).aspx
Page 11
Deploying the Server Side Applications
The steps for building the servers described in the previous section can also be used to prepare the
servers for the server-side applications. Detailed guidance for setting up the server-side applications is
discussed under the following headings.
Process
Though the server will be set up to meet the needs of your specific applications, additional steps may be
needed to prepare the hardware for deployment.
 To deploy server-side applications, follow these steps:
1. Install the operating system and third-party components on the server as required by the
application.
2. Configure the server-side application components.
3. Install the server-side components on the server.
4. Add all configuration information into the configuration management database (CMDB)
and maintain change control of the release. If a CMDB does not exist, a simplified one
should be created for release-tracking. Updating the CMDB ensures that accurate
knowledge is stored regarding all of the components or configuration items that make up
the releases.
5. Deploy the applications in conjunction with the deployment strategy being employed for
the databases.
6. Once the database migration has been confirmed, perform configuration changes to the
environment to activate the application.
7. If a fallback is required, then the application should be shut down and the original
configuration that points all users back to the original application should be restored.
Technology
Refer to the TechNet deployment for the latest options, tools and best practices. Links are provided in
the above sections.
Deploying the Client Application
After the server-side applications and databases have been deployed to production and tested, the
client application should be released. Often, this stage of the deployment can be complex due to the
number of users and components involved.
This is usually the point in the deployment process where the end users are affected. In many cases, this
is the first time that they are involved in the migration process. While this guidance focuses on the
application and database aspects of the migration, keep in mind that there are many other items to
consider. For instance, documentation, training, and helpdesk support also need to be in place at the
time of this deployment.
Page 12
It is quite likely that the client computers are already in use. If not, build the hardware for the client
computers and deploy the required software.
Process
As with the other stages of deployment, the client application can be deployed manually or through the
use of automated tools. Consider the following steps when deploying the client application.
1. Create the deployment package, which can include the following:
The complete application, including the binary installation files and any automation files.

Client configuration and support files.

Windows domain user accounts configuration scripts.

Scripts for configuring ODBC data sources, ADO, or OLE DB connection strings.

Scripts for configuring COM+ components for database connection.

Acceptance test scripts and packages.
2. Create rollback scripts to remove changes introduced by the deployment. Rollback scripts
provide an alternate option if an uncorrectable issue arises during the server, database, or
application deployments.
3. Add the deployment package to the configuration management database (CMDB).
Maintain change control of the release. Where a CMDB does not exist, a simplified one
should be created for release-tracking.
4. Once the database and application migration are completed successfully, deploy the client
application. In addition to the database and application deployment strategy, a horizontal
phase-out strategy may be employed for client applications.
5. If a fallback is required, then the application should be rolled back to the previous one and
the original configuration that points all clients back to the original application should be
restored. If the fallback is due to an application issue, then a horizontal phase-out strategy
reduces the rollback effort.
Technology
When deploying the client application, additional tools may be required to efficiently manage the
deployment. Some common tools used for packaging applications and utilizing distribution channels
include:
●
MSI (or Windows Installer) is a Microsoft solution for application packages. This installer
provides additional functionality and integration with the Windows environment,
including elevated privileges for installation and deployment across an Active Directory.
To download Windows Installer or learn more about it, refer to:
http://www.microsoft.com/en-us/download/details.aspx?id=8483.
●
●
InstallShield AdminStudio can also create a scripted package file or an MSI package.
Page 13
For more information about InstallShield, refer to:
http://www.installshield.com/downloads/isas/evalguide/AdminStudio5_Evaluator_Guide.pdf.
●
●
●
Active Directory is a core feature in the Windows server operating system which not only
handles security and privileges of the domain, but also has the capability to distribute MSI
files. Group Policy settings can be set in Active Directory to distribute the required MSI
file. Active Directory can be used efficiently to distribute the files at off hours or weekends
to avoid blocking network congestion. For further information about Active Directory,
refer to: http://technet.microsoft.com/en-us/library/hh831769
●
System Center 2012 is a tool from Microsoft for distributing software packages. SMS has
various features, such as packaging, distributing, deploying applications, and monitoring.
For step-by-step procedures for distributing a package using SMS, refer to:
http://www.microsoft.com/en-us/server-cloud/system-center/configuration-manager2012.aspx.
Note: The tools listed above have not been tested in a lab environment as part of this
solution.
Change Management
Change management is the process for controlling changes to a protected environment. In the
Stabilizing Phase, changes are made to the test environment related to bug fixes and promoting the
builds. Changes made to the solution in the production environment are handled more strictly because
they can affect the end users of the application as well as other users of the production environment.
Any proposed changes must go through the change approval process to ensure that the changes will not
adversely affect the production environment.
Microsoft Operations Framework (MOF) delivers practical guidance for everyday IT practices and
activities, helping users establish and implement reliable, cost-effective IT services. It encompasses the
entire IT lifecycle by integrating:
Community-generated processes for planning, delivering, operating, and managing IT.
Governance, risk, and compliance activities.
Management reviews.
Microsoft Solutions Framework (MSF) best practices.MOF guidance can be found here:
http://technet.microsoft.com/en-us/library/cc506049.aspx
Page 14
Stabilizing the deployment
After the server-side application components, database, and client-side application components are
deployed, every aspect of the deployment must be validated to ensure that the migration has been
performed successfully. Common items to check are included in the deployment checklist discussed in
the following sections.
Deployment Checklist
The product manager and the operations team should ensure that the solution meets the business
requirements and standards determined during the Envisioning Phase. The checklist developed during
the Planning Phase should contain the acceptance criteria that evaluate the performance of the
solution. It should also provide a baseline for the customer to approve the solution. The following
categories should be included in the checklist to test the solution before signoff:
●
Server
●
Database
●
Application (client and server side)
●
Additional considerations
These categories are discussed under the following headings.
Server
The following are some server-related items that should be considered for the checklist:
●
Have all relevant service packs been loaded to the production servers? Are the OS and
installed service pack level well known and documented? You will need this information if
the systems fail and manufacturer support is required.
●
Have the settings from the performance tuning in the test environment during the
Stabilizing Phase been transferred correctly? At the same time, ensure that any
configurations unique to the testing environment have not been transferred to the
production environment.
●
Have backup power systems been fully tested to ensure proper operation?
●
Are an appropriate number of replacement hard disks on hand in case of failure in an
array?
●
Are the default client connection network library settings established on the server?
●
Are all database and application server installation settings documented (sort orders,
default language, and so on)?
●
Has communication between servers been checked to assure that proper DNS resolution
and routing is functioning as expected?
●
Are alerts defined for key problems and conditions? Who monitors the e-mail address to
which these are sent? Are pagers used? Has the alert system been tested?
Page 15
●
Has the team removed guest accounts from the system and checked to ensure that this
does not affect the application?
●
Is the appropriate level of directory security set?
●
Has security logging been implemented?
●
Have all non-essential services and open ports on the server been identified and closed?
●
Has the team tested production integration with third-party systems?
●
Have any and all event log messages been identified and investigated?
●
Does the OS have sufficient client access licenses for the expected peak traffic loads?
●
Are sufficient client access licenses and connections installed for the OS? Is this being
monitored to assure that it does not reach its limit?
●
Are system configurations for all tiers backed up? Were scripts created to reset
configurations in an emergency or to bring up a new server? Are they in a well-known
location?
●
Have server backups been tested? Are procedures in place for proper storage and
retrieval?
●
Have clustering software configuration and failover operations been tested?
Database
The following are some database-related items that should be considered for the checklist:
●
Have all database creation scripts been executed properly and without errors?
●
Were the database statistics updated prior to launch?
●
Have the database backups been tested to ensure that backup mechanisms are operating
properly? Have restoration procedures been tested on the solution server and on
different hardware to test failover procedures? Are off-site backup procedures in place?
●
Has database security been addressed and appropriate logon accounts created? Is the
system administrator's (SA) account password blank? Are applications using the SA
account or other account(s)?
●
Did the team define, test, schedule, and sign-off on maintenance plans?
●
Has a schedule been established for the transaction log dumping that will be sufficient to
recover activity to the satisfaction of the business? Has it been tested?
●
Are sufficient client access licenses installed for the database server? Are these being
monitored to assure that they do not reach their limit?
●
Has the latest build of the database from the development environment been migrated,
installed, tested, and verified within the production environment?
●
The user databases should be checked to ensure that all the data from the database is
transferred from the source solution to the target solution during deployment.
●
Has the database been loaded in the production environment with clean data, and have
initial inventory levels been set? Have feeds from other systems been verified under load
to ensure that system availability is unaffected at the time they run?
Page 16
●
Is the database running on the default port of 1433? If so, can this be changed to another
port or ports to enhance security of the application without affecting proper operation?
●
Are non-essential SQL Server services running (MS Search, OLAP)? Stop them if they are
not required.
●
Are non-essential databases installed on the server? Remove databases such as pubs or
Northwind, but be careful not to remove needed system databases such as model,
tempdb or master.
●
Is the database correctly tuned, and does it have the proper memory usage settings
applied?
●
Is disk space sufficient for the expected size of the data 6-12 months ahead?
●
Have clustering software configuration and failover operations been tested with the
databases?

Are the high availability components in place correctly? SQL Server 2012 introduces a new
high availability functionality in AlwaysOn. Educate yourself on this new technology and
how to enable it in your environments.
o
AlwaysOn
o
Windows Server Failover Clustering
o
Mirroring (note that this functionality is being deprecated.
o
Replication
o
Log Shipping
o
Backup/Restore
o
Database Snapshots
Application (Client Side or Server Side)
The following list offers some client-side or server-side application-related items that should be
considered for the checklist:
●
Are the proper security settings for the applications set and documented?
●
Has application logging been enabled or disabled, as required?
●
Has the golden release of the applications and other components been given a release
number, archived, then deployed? Confirm that the golden release of the source code
matches the version of the application that was released.
●
Are all required environmental settings for the applications set and documented?
●
Are all third-party software or components that are required by the system installed and
documented (version numbers, vendor contact information, and so on)?
●
Ensure that the client application properly connects to the database. Perform cursory
testing of the application that is not intrusive and does not change the production
database. For example, running production reports is a good way to test database
functionality without changing the live data.
●
Has connectivity between the middle-tier system and any back-end systems been tested
under load? Has connection pooling been monitored to assure proper operation?
Page 17
●
Are the activation types for any COM+ applications set properly? Has the application been
tested with the consoles logged on and logged off to assure the proper identity is used?
●
Has the application integration been tested with third-party systems?
●
Have clustering software configuration and failover operations been tested with the
applications?
Additional Considerations
Here are some additional considerations that could apply to your environment. Some of the tasks
performed here are related to operations. Validating these tasks during deployment ensures operations
are prepared to manage the solution and SLAs can be met.
●
Are scheduler jobs defined for common tasks? Jobs like backups, health reporting, etc, is
normally scheduled through a scheduler like cron in Unix. These may have been migrated
over.
●
Is a disaster recovery plan (DRP) established that includes database procedures? Who is
the DRP team leader? Is the leader's contact information well known, and is a contingency
leader appointed?
●
Are the change-control procedures enabled for the operations environment?
●
Are the finalized the operational processes and guidelines in place?
●
Has the team developed, tested, and simulated disaster recovery procedures?
●
Was an external connection used when testing the application against the operations
system? The external connection should be similar to what a customer will use.
●
Was solution training delivered?
●
Is the processing speed acceptable?
●
Have the business objectives and requirements been met?
●
Have operation tests been performed? Steps should be taken to make sure that the
operations team can properly track the servers and services with their monitoring tools.
Quiet Period
The quiet period for the target environment begins after stabilizing the deployed solution and continues
until the deployment is complete. It usually exists for a period of 15 to 30 days. During this period the
operations team manages the deployed solution.
No significant changes should be made to the solution. However, a member from the project team may
aid the operations team to manage and resolve problems that can affect the working of the deployed
solution. This enables the organization to estimate the maintenance costs of the solution and prepare a
budget. Changes made to the solution will be through the process of change management.
During the quiet period the efficiency of the solution can be ascertained by evaluating the
●
Solution's stability
Page 18
●
Solution's downtime
●
Maintenance required by the solution
Transferring Ownership to Operations
The final transition occurs when the project team completes its tasks and transfers the infrastructure,
documentation, and operations to the Operations team. The ownership of the solution is also
transferred to the Operations team.
The Operations team has to understand the functioning of the solution and manage it. The solution's
documentation should supply information required to manage the solution.
The Operations team will require the following documents to handle the solution after migration:
●
User manual. The user manual details the procedures for working with the solution. It
also details the procedures for installation and solution maintenance.
●
Hardware specifications. This document describes the hardware used in the production
environment.
●
Software specifications. This document covers the different applications, such as thirdparty software used by the solution itself or used to stabilize the deployment. The
software specifications also detail the different configurations and settings applied to the
solution during or after the installation and deployment of the solution.
●
Support policies and procedures. This document details the updated business policies
and procedures that need to be followed after the migration is complete.
Project Team Tasks
The project team will examine the deployment to ensure that all areas of the deployment are
successfully completed and functioning as required. A final run of the tests that caused discrepancies
can be used to check that they have been fixed. The project team ensures that:
●
All the procedures of the migration have been followed.
●
Backups are performed as required.
●
All security measures (hardware and software) are in place and operate without issues.
●
All errors and bugs are fixed.
●
Adequate training is provided to operations to manage the solution.
●
Different user accounts have been created and checked for their functionality.
Operations Team Tasks
The operations team will check the solution to ensure that it conforms to the business objectives. The
operations team will:
Page 19
●
Conduct a final run through of the solution to check its performance and stability.
●
Ensure that the project team has completed all the tasks needed to complete the
deployment.
●
Check that the tools to perform routine tasks are set up.
●
Review the documentation.

Decide the frequency for performing routine tasks.
Page 20
CONCLUSION
After the deployment of the solution is complete, the team conducts a review meeting to assess the
migration project. This review covers all the phases of the migration project, including the Envisioning,
Planning, Developing, Stabilizing and Deploying Phases. By taking the time to discuss the entire
migration project, important lessons can be learned and applied to future endeavors. This will also
highlight the positive actions taken to successfully migrate the solution, and the less positive decisions
or actions that delayed or hindered the migration. The project review can also compare the estimated
outcome of the migration project with the actual targets achieved.
The customer sign-off signifies the end of the Deploying Phase. The solution's key stakeholders review
the migrated solution and documentation and confirm that the needs of the project have been met.
Once this sign-off has been received, the project team can be disengaged. The exact terms of this sign
off will depend on the migration requirements for the project.
Page 21