Human Resources Data Migration Project
Implementation Plan
Human Resources Data Migration Project
Implementation Plan

Project Group 1:
Information Technology Group
March 4, 2013
Project Group 1:
Information Technology Group
March 4, 2013

VERSION HISTORY

Version # | ImplementedBy | RevisionDate | RequestedBy | ApprovedBy | Description of Change | 1.0 | student | 03-04-2013 | | | Preliminary draft | | | | | | | | | | | | | | | | | | |

Table of Contents
1.1 Purpose 4
1.2 System Overview 4 1.2.1 System Description 4 1.2.2 Assumptions and Constraints 4 1.2.3 System Organization 5
2 Management Overview 5
2.1 Problem Statement 5
2.2 Description of Implementation 6
2.3 Points-of-Contact 6
2.4 Major Tasks 7 2.4.1 Project Tasks 7 2.4.2 MS Access to Oracle Tasks 7 2.4.3 Oracle to Mongo Tasks 7
2.5 Implementation Schedule 8
2.6 Security and Privacy 8 2.6.1 System Security Features 8 2.6.2 Security Set Up During Implementation 8 3 Implementation Support 8
3.1 Hardware, Software, Facilities, and Materials 9 3.1.1 Hardware 9 3.1.2 Software 9 3.1.3 Facility 9 3.1.4 Materials 9
3.2 Documentation 9
3.3 Personnel 9 3.3.1 Staffing Requirements 9 3.3.2 Training of Implementation staff 9
3.4 Outstanding Issues 10
3.5 Implementation Impact 10
3.6 Communications Plan 10
3.7 Change Management 12 4 Implementation Risks and Contingencies 13
4.1 Technical Risks and Contingencies 13
5 Acceptance Criteria 14
6 Implementation Verification and Validation 14
APPENDIX A: Project Implementation Plan Approval 15
APPENDIX B: REFERENCES 16
APPENDIX C: SECURITY FEATURES 17
APPENDIX D: MIGRATION DETAILS 21
1.1 Description of Access to Oracle Implementation 21 *
Introduction
1.1 Purpose

The implementation plan describes the migration of data from an MS Access database to Oracle and MongoDB.
1.2 System Overview

The systems in scope for this data migration are databases. The current HR data resides in an Access Database running on a user desktop and lacks the necessary security and access control needed to be in compliance with the existing security policy.
1.2.1 System Description

Access Database: This is a database management system from Microsoft that combines the relational Microsoft Jet Database Engine with a graphical user interface and software-development tools. This system is no suitable for enterprise use and data security is limited to user password protection.

Oracle Database: This is a database management system, built around a relational database framework in which data objects can be directly access by users (or an application front end) using a structured query language (SQL). Oracle provides a comprehensive portfolio of security solutions (i.e. encryption, access control) to ensure data privacy, protect against insider threats, and enable regulatory compliance.

MongoDB: This is an open source document-oriented database system. It is part of the no structure query language (NoQSL) family of database systems. Instead of storing data in tables as is done in a "classical relational database”, MongoDB stores structured data as Java Script Object Notation (JSON) like documents (text based) with dynamic schemas, making the integration of data in certain types of applications easier and faster.
1.2.2 Assumptions and Constraints

The following assumptions will be considered for this data migration:

* Schedule: The data migration will be done over a weekend, to avoid any potential disruption to the other systems using the Oracle and MongoDB systems. * Budget: The budget will only account for the resources needed to complete the migration. * Resources: The project will use existing resources and will provide training. * Software: The Company has Oracle and MongoDB w/enterprise license already, so there is no need to purchase additional licenses. * Hardware: The Oracle and MongoDB databases are already in use, so there is no need to purchase additional hardware. * Constraints: There are no downtime constraints to execute the migration, and a copy of the data is ready available.
1.2.3 System Organization
The current systems are in place. The Oracle and MongoDB servers are in compliance with existing security policies, but the Access database is running on a user desktop exposing the confidential HR data to unauthorized access due to the weak Windows security in place. The diagram below shows the current setup.

Oracle server
Enterprise Network
MongoDB server
User desktop w/ Access DB
User desktop
User desktop
Security Policy
Current Systems Setup
Secured
Datacenter
Unsecured
Office Area

Oracle server
Enterprise Network
MongoDB server
User desktop w/ Access DB
User desktop
User desktop
Security Policy
Current Systems Setup
Secured
Datacenter
Unsecured
Office Area

2 Management Overview

During an IT audit of the company’s systems, policies and procedures, auditors discovered that that employee health data is being stored in an unsecure and unprotected Access Database within the Human Resources Department.
Auditors could not determine who has access to this data since no logs or record keeping regarding access was ever kept. The liability to both the company and the employees for any breach in the HIPAA protected data can result in extremely large fines and employees being fired and possibly sued.
The Human Resources Department has engaged the Information Technology Team to review the issues and both have agreed to migrate the data to a secure Oracle and Mongo DB; and restrict access to authorized personnel by job function using the existing access control system.
2.1 Problem Statement

A recent audit review has revealed the following issues related to employee health data privacy. These issues are a violation to the existing company security policy, and also to the regulatory compliance laws enacted under the Health Insurance Portability and Accountability Act (HIPAA) of 1996. * The Human Resources department uses an unsecured Microsoft Access database to store employee confidential health data. * The Human Resources department works in a silo. The Access Database is running in non-standard hardware not supported by the IT department. * The Access Database does not comply with corporate access control and security policies. * The Human Resources group does not know who has access to the data and do not keep logs for auditors. * The quality of the data has been compromised with inaccurate information, duplicate and missing records. * The company faces serious legal and reputational risk for non-compliance with public law and employee privacy policy respectively.
2.2 Description of Implementation

The project implementation consists of moving HR data from Access Database to Oracle and to Mongodb. The following diagram shows the migration flow:

2.3 Points-of-Contact

Role | Name | Contact Number | Business Sponsor | Marc Paller | 212-333-5555 | Project/Program Manager | Darrell Austin | 212-333-6666 | Database Administrator 1 | Ricardo Salas | 212-333-7777 | Database Administrator 2 | Chandrika Ganesan | 212-333-8888 | Oracle Engineer | John Dover | 212-561-3000 | | | | Table 2.2 – Points-of-Contact

2.4 Major Tasks
2.4.1 Project Tasks

1. Create implementation plan 2. Obtain implementation plan approval 3. Assemble project team 4. Personnel training – Oracle 5. Data migration – Access to Oracle 6. Data migration – Oracle – Mongodb 7. Configure db access control - Permissions 8. User acceptance test 9. IT Operations signed off to support new HR database 10. Obtain project closure approvals

2.4.2 MS Access to Oracle Tasks

1. Create a new Database User 2. Create a migration repository 3. Capture MS Access exported XML 4. Set Conversion preferences 5. Convert to Oracle Model 6. Scripts to create Oracle objects 7. Data move preferences 8. Migrate Data 9. User acceptance test

2.4.3 Oracle to Mongo Tasks

1. Extract Data 2. Import Data 3. User acceptance test

2.5 Implementation Schedule

2.6 Security and Privacy

The data in scope contains personal data and data security is of utmost importance to be compliant with the existing security policies and Privacy Act.
The following security measures are in place:

* Data transfer will be done only using SFTP * Data depositories or servers have to be in compliance with existing security policies * Data will be handle by authorized personnel * Outside vendors will have to sign a Non Disclosure Agreement and obtain security clearance to work on the project.
2.6.1 System Security Features

Oracle 11g has enhanced security features, while MongoDB relies on external security sources like application level encryption and Kerberos for authentication. See appendix C.

2.6.2 Security Set Up During Implementation

This section is not applicable to the data migration. The target Oracle and Mongodb servers are installed in a secured location. The data will be transfer using secure file transfer protocol (SFTP) and access to the data is limited to the project implementation team only.

3 Implementation Support

3.1 Hardware, Software, Facilities, and Materials
3.1.1 Hardware

This section is not applicable to the project. The hardware is already in place and operational.
3.1.2 Software

This section is not applicable to the project. The software in scope, Oracle 11g and Mongodb, are already being used by the company.
3.1.3 Facility
The servers in scope of this migration are located in the Main datacenter. The work can be done remotely, and there is no need to request datacenter access. In the event of a problem requiring datacenter access, the IT team has on site personnel available to assist.

3.1.4 Materials
This section is not applicable to the project.
3.2 Documentation
The project documentation will be saved in the IT group shared drive and the “Operational Turned Over Document” will be sent to the IT group for approval. Upon acceptance, the IT group will be responsible for the ongoing support of the HR data.

3.3 Personnel
3.3.1 Staffing Requirements

The personnel needed for this implementation will be from existing resources with the addition of an Oracle database person hired to assist and trained current personnel. The table below shows the personnel listed and the hours allocated for the project.

Project Resources | Category | Rate | Hours | Total USD | Project Manager | Employee | $100.00 | 40 | $4,000.00 | Database Administrator 1 | Employee | $75.00 | 40 | $3,000.00 | Database Administrator 2 | Employee | $75.00 | 40 | $3,000.00 | UAT Tester 1 | Employee | $85.00 | 8 | $680.00 | UAT Tester 2 | Employee | $85.00 | 8 | $680.00 | Oracle Engineer | Vendor | $140.00 | 40 | $5,600.00 | Total | 176 | $16,960.00 |

3.3.2 Training of Implementation staff

The existing support personnel will be trained in Oracle 11g. The Oracle engineer will give a 2 day overview of the Oracle Database including:

* Install Oracle Grid Infrastructure. * Create and manage users. * Install and configure an Oracle Database. * Create and manage storage structures. * Administer the Oracle Database. * Understand the Oracle database architecture and how its components work and interact with one another. * Perform backup and recovery. * Database security * Create an operational database and properly mange the various structures in an effective and efficient manner.
3.4 Outstanding Issues
None
3.5 Implementation Impact
There is no impact to the existing infrastructure. The network and servers have adequate processing power and disk capacity to handle the HR data volume.
The operational support of the HR database will be transitioned from the business side to the IT team. The IT database administrators are being trained to support Oracle, and they have the Mongodb knowledge.
Existing SLAs will remain in place, and all calls related to the HR data will flow through the Help desk as of today. 3.6 Communications Plan

The communications plan is the key to a successful project. Clearly and concise information will be delivered in the meetings with all the groups involved. The meetings will be scheduled via outlook and invitations will be sent to all stakeholders with meeting details including a conference bridge to dial-in if anyone is unavailable to meet in person.
The project manager will chair the meetings, take notes and is responsible to send meeting minutes after each meeting and follow up on all tasks assigned to ensure timely completion.
All project stakeholders are responsible to attend the meeting or send a representative if they have a conflict.
The tables below show the communications plan for the project stakeholders and project team members respectively.

The following table shows the communications plan for the project stakeholders and sponsor. Purpose of Communication | Target audience | Purpose of Communication | When / Frequency | Methods of Communication | Project initiation | Project sponsor, Project Manager and IT Director | Gather information for Initiation Plan | First meeting | Meeting | Implementation plan approval | All stakeholders | Distribute implementation plan to communicate project scope and get sponsor and senior management approvals. | Before Kick Off Meeting | Meeting and Distribute minutes via email. | Project Kick Off | All stakeholders | Communicate plan and stakeholder roles / responsibilities. | At or near Project Start Date | Meeting and Distribute minutes via email. | Project Review and Status Report | All stakeholders | Update stakeholders on progress of the project, and communicate potential risks and issues that might affect scope, schedule or budget. | Bi-weekly | Meeting and Distribute minutes via email | Sponsor Meetings as needed | Sponsor(s) and Project Manager | Update Sponsor(s) on status and discuss critical issues. Seek approval for changes to Project Plan. | Ad hoc | Meeting | PMO Audit/Review | Project Office, Project Manager, select stakeholders, and Sponsor. | Review status reports, issues, and risks. Identify and communicate potential risks and issues that may affect scope, schedule or budget. | Monthly | Meeting/Report | Post Project Review | Project Office, Project Manager, key stakeholders, and sponsor(s). | Identify improvement plans, lessons learned, what worked and what could have gone better. Review accomplishments. | End of Project | Meeting/Report |

The table below shows the communications plan for the project team. Purpose of Communication | Target audience | Purpose of Communication | When / Frequency | Methods of Communication | Team kick off Meeting | Project Team | Review detailed plans and assign roles and responsibilities. | First team meeting | Meeting / Conference Call | Team Meetings | Project Team | Review project deliverables, risks, and issues that might effect scope, schedule or budget. | Weekly | Meeting / Conference Call and distribute meeting minutes via email | Other… | To be determined by the Project Team | General communications | As needed | Meeting / Conference call / email | Post Project Review | Project team | Identify improvement plans, lessons learned, what worked and what could have gone better. Review accomplishments. | End of Project | Meeting / Conference Call and distribute report |

3.7 Change Management

The project will follow the existing change control processes for all project work. The changes will follow all phases shown in the below change management process flow:

There are two types of changes in the project lifecycle and both require an approved change request.

Scope change
These changes typically fall outside of the project charter and are driven by a problem encounter during implementation or new business requirements. The project team must evaluate the change and assess the impact on time, cost, risk, quality, resources and customer satisfaction.
The project manager is the only person that can approve the change requested by the project team members or the sponsor, and is responsible to communicate the change to the sponsor and stakeholders seeking their approval.

Project change
These changes are planned and needed to implement the approved solution or scope of work as agreed in the project charter. The project team writes schedules and executes the change. The project manager represents the change in the weekly Change Management Meetings to seek approvals.
As part of the existing Change Management Policy, all changes have to follow the below criteria: * Must be submitted a week in advance * Must have clearly defined scope and impact * Must include a test plan * Must include a rollback plan * Must be fully approved before any work is started

4 Implementation Risks and Contingencies

There are only technical risks associated with this implementation.

4.1 Technical Risks and Contingencies

The table below shows the risks associated with the data migration, the impact to the project and the actions needed to mitigate the risk if applicable.

Risk Type | Risk Title | Risk Impact | Mitigation Plan | Technical | Data corruption | Implementation delay | None | Technical | ETL failure | Implementation delay | Pre-migration test | Technical | Hardware failure | Implementation delay | Available spare part | Technical | Incorrect data Format | Implementation delay | Pre-migration test | Technical | Technical knowledge | Operational support | Train support personnel |

5 Acceptance Criteria

The acceptance criteria are based on data availability, integrity, security and performance.

Availability: The migrated data is available from oracle and MongoDB to the different systems in place, as it was before the migration.

Integrity: The structure of the migrated data is consistent with the formats needed by the systems in place.

Security: The migrated data is encrypted and access has been secured by job function keeping a log for auditors.

Performance: The migrated data can be accessed, computed and saved in the same time as before (no additional latency) or faster.

Support: The IT team has agreed to support HR data, and signed off the Operational Turnover documentation.

Usability: The business testers will perform a user acceptance test to validate the usability of the data and successful completion of all the processes depending on the HR data in scope.

6 Implementation Verification and Validation

The database administrators and business testers will perform the data migration verification and validation. The success of the data migration will be based on the agreed acceptance criteria below.
The contingency plan for the data migration is simply to point all the applications back to the Access Database server. The Access database server will not be compromised by this migration, and all data will stay intact.

APPENDIX A: Project Implementation Plan Approval
The undersigned acknowledge that they have reviewed the Human Resources Data Migration Plan and agree with the information presented within this document. Changes to this Project Implementation Plan will be coordinated with, and approved by, the undersigned, or their designated representatives. Signature: | | Date: | | Print Name: | | | | | | | | Title: | | | | Role: | Project Manager | | |

Signature: | | Date: | | Print Name: | | | | | | | | Title: | | | | Role: | Project Sponsor | | |

Signature: | | Date: | | Print Name: | | | | | | | | Title: | | | | Role: | Chief Information Officer | | |

APPENDIX B: REFERENCES
The following table summarizes the documents referenced in this document. Document Name | Description | Location | Human Resources Data Migration Project | Data Migration Plan | Epsilen Drop Box | | | | | | |

APPENDIX C: SECURITY FEATURES

ORACLE 11G
Automatic Secure Configuration

When you create a new database, you can use Database Configuration Assistant (DBCA) to automatically create a more secure configuration than in previous releases of Oracle Database. You can enable the following secure configuration settings in one operation:
Password-specific settings in the default profile. This feature enables you to enforce password expiration and other password policies. See "Configuring Password Settings in the Default Profile" for more information.
Auditing. This feature enables auditing for specific events such as database connections. See "Using Default Auditing for Security-Relevant SQL Statements and Privileges" for more information.
New Password Protections

Oracle Database now includes the following new password protections:
Easy ability to find default passwords. If you have upgraded from an earlier release of Oracle Database, you may have user accounts that still have default passwords. For greater security, you should find and change these passwords. See "Finding User Accounts That Have Default Passwords" for more information.
Password complexity verification. Password complexity verification ensures that users set complex passwords when setting or resetting passwords. You can enforce password complexity by using the default settings provided by Oracle Database, or create custom requirements to further secure the password complexity requirements for your site.
"Enforcing Password Complexity Verification" describes built-in password verification.
Enforced case sensitivity. See "Enabling or Disabling Password Case Sensitivity" for more information.
Stronger password hashing algorithm. This enhancement enables users to create passwords that contain mixed case or special characters. See "Ensuring Against Password Security Threats by Using the SHA-1 Hashing Algorithm" for more information.
SYSDBA and SYSOPER Strong Authentication

You can now use the Secure Sockets Layer (SSL) and Kerberos strong authentication methods to authenticate users who have the SYSDBA and SYSOPER privileges.
See "Strong Authentication and Centralized Management for Database Administrators" for more information.
SYSASM Privilege for Automatic Storage Management

The SYSASM system privilege has been added to Oracle Database 11g Release 1 (11.1), to be used exclusively to administer Automatic Storage Management (ASM). Use the SYSASM privilege instead of the SYSDBA privilege to connect to and administer ASM instances.
Encryption Enhancements
Intelligent LOB Compression, Deduplication, and Encryption with SecureFiles

Oracle Database supports a new, faster, and scalable Large Object (LOB) storage paradigm called SecureFiles. SecureFiles, in addition to performance, supports efficient compression, deduplication (that is, coalescing duplicate data), and encryption. LOB data can now be encrypted with Oracle Database, and is available for random reads and writes.
Compressed and Encrypted Dump File Sets

In this release, you can use Oracle Data Pump to compress and encrypt an entire dump file set. You can optionally compress and encrypt the data, metadata, or complete dump file set during an Oracle Data Pump export.
Transparent Data Encryption with Hardware Security Module Integration

Transparent data encryption (TDE) stores the master key in an encrypted software wallet and uses this key to encrypt the column keys, which in turn encrypt column data. While this approach to key management is sufficient for many applications, it may not be sufficient for environments that require stronger security. TDE has been extended to use hardware security modules (HSMs). This enhancement provides high assurance requirements of protecting the master key.
This release enables you to store the TDE master encryption key within a hardware security module (HSM) at all times, leveraging its key management capabilities. Only the table keys (for TDE column encryption) and tablespace keys (for TDE tablespace encryption) are decrypted on the HSM, before they are returned to the database; the encryption and decryption of application data remains with the database. Oracle recommends that you encrypt the traffic between HSM device and databases. This new feature provides additional security for transparent data encryption, because the master encryption key cannot leave the HSM, neither in clear text nor in encrypted format. Furthermore, it enables the sharing of the same key between multiple databases and instances in an Oracle Real Applications Clusters (Oracle RAC) or Data Guard environment.
Transparent Tablespace Encryption

Transparent tablespace encryption enables you to encrypt entire application tablespaces, encrypting all the data within these tablespaces. When a properly authorized application accesses the tablespace, Oracle Database transparently decrypts the relevant data blocks for the application.
Transparent tablespace encryption provides an alternative to TDE column encryption: It eliminates the need for granular analysis of applications to determine which columns to encrypt, especially for applications with a large number of columns containing personally identifiable information (PII), such as Social Security numbers or patient health care records. If your tables have small amounts of data to encrypt, then you can continue to use the TDE column encryption solution.
Fine-Grained Access Control on Network Services on the Database

Oracle Database provides a set of PL/SQL utility packages, such as UTL_TCP, UTL_SMTP, UTL_MAIL, UTL_HTTP, and UTL_INADDR, that are designed to enable database users to access network services on the database. Oracle Database PL/SQL Packages and Types Reference describes the PL/SQL utility packages in detail.
In a default database installation, these packages are created with the EXECUTE privilege granted to the PUBLIC role. This release enhances the security of these packages by providing database administrators the ability to control access to applications in the database that use these packages.
Change to AUDIT BY SESSION

The BY SESSION clause of the AUDIT statement now writes one audit record for every audited event. In previous releases, BY SESSION wrote one audit record for all SQL statements or operations of the same type that were executed on the same schema objects in the same user session. Now, both BY SESSION and BY ACCESS write one audit record for each audit operation. In addition, there are separate audit records for LOGON and LOGOFF events. If you omit the BY ACCESS clause, then BY SESSION is used as the default.
Be aware that this change applies only to statement options and system privileges that audit SQL statements other than data definition language (DDL) statements. The database has always audited using the BY ACCESS clause on all SQL statements and system privileges that audit a DDL statement.
Oracle XML DB Security Enhancements
XML Translation Support for Oracle Database XML

Security objects are now stored in the Oracle XML DB repository as XMLType objects. These security objects can contain strings that need to be translated to different languages so that they can be searched or displayed in those languages. Developers can store translated strings with the XMLType and retrieve and operate on these strings depending on the language settings of the user. The advantage of this feature is that it reduces the costs associated with developing applications that are independent of the target-preferred language of the user.
Support for Web Services

You can now use the Oracle XML DB HTTP server for service-oriented architecture (SOA) operations. This allows the database to be treated as simply another service provider in an SOA environment. Security administrators can control user access to Oracle Database Web services and their associated database objects by using the XDB_WEBSERVICES, XDB_WEBSERVICES_OVER_HTTP, and XDB_WEBSERVICES_WITH_PUBLIC predefined roles.
Directory Security Enhancements

In this release, administrators can now disallow anonymous access to database service information in a directory and require clients to authenticate when performing LDAP directory-based name look-ups. If you are using Microsoft Active Directory-based name lookups, then Oracle Database uses the native operating system-based authentication. If you are using Oracle Internet Directory (OID)-based name lookups, then Oracle Database performs authentication by using wallets.
Oracle Call Interface Security Enhancements

The following security enhancements are available for Oracle Call Interface (OCI):
Reporting bad packets that may come from malicious users or intruders
Terminating or resuming the client or server process on receiving a bad packet
Configuring the maximum number of authentication attempts
Controlling the display of the Oracle database version banner, to prevent intruders from finding information about the security vulnerabilities present in the database software based on the version
Adding banner information, such as "Unauthorized Access" and "User Actions Audited," to server connections so that clients can display this information.

APPENDIX D: MIGRATION DETAILS

1.1 Description of Access to Oracle Implementation
Oracle SQL Developer Migration Workbench will be used to migrate MS Access DB to Oracle. The implementation steps are enumerated below.

1.1.1 Create a new Database User

* Open SQL Developer and connect to the app11g DB that is already setup. * On the SQL Worksheet following commands will be executed to create the user. CREATE USER EAIREP IDENTIFIED BY eairep DEFAULT TABLESPACE USERS TEMPORARY TABLESPACE TEMP;

GRANT CONNECT, RESOURCE, CREATE SESSION, CREATE VIEW TO EAIREP;

1.1.2 Create a Migration Repository

To convert the MS Access XML file to the required tables in Oracle: * Create a new database connection for EAIREP user with the following properties and click connect to connect to the DB as EAIREP user:

Connection Name : EAIFINAL_PROJECT
Username : EAIREP
Password : eairep
Hostname : oit.scps.nyu.edu
Port : 1521
SID : app11g

* Right-click on EAIFINAL_PROJECT and select Migration Repository -> Associate Migration Repository and click close when the install completes.

1.1.3 Capture MS Access exported XML

Perform the following steps to capture the Access XML that has already been exported and downloaded in the capture directory:

* Click on migration -> Microsoft access captured XML. * Select the EAIFINAL.xml file from the dialog box and click OK to capture. * Check the captured models tab and expand EAIFINAL and verify the list of objects that were captured. 1.1.4 Conversion Preferences

Select ‘Is Quoted Identifier On’ from Tools->Preferences->Migration Identifier options.

1.1.5 Convert to Oracle Model

* Right-click on the captured EAIFINAL Access model and select convert to Oracle Model. * Click apply on the source data map window to convert to oracle model. * Verify the converted objects from the converted models tab.

1.1.6 Scripts to create Oracle Objects

To Generate the DDL statements to create Oracle objects perform the following steps:

* Right-click on the converted EAIFINAL and click on generate to create the SQL. * Execute the SQL from the SQL worksheet as user <username>.by clicking on the <connection name> from the connections. * Expand tables and verify that the tables have been created.

1.1.7 Data move preferences

Set the timestamp mask to the following: yyyy-mm-dd HH24:mi:ss.ff3 from Tools->Preferences->Migration->Data Move Options -> Date Mask ->Timestamp Mask.

1.1.8 Migrate Data

* Click on the converted models generated from step 2.1.5 and select Generate Offline Data move scripts and data files. * .Open a DOS prompt and CD to change to the directory where the data files and scripts are located. * From the command prompt execute oracle_ctl.bat file.
<c:/accessDataFiles> oracle_ctl * Click on tables->refresh in SQL Developer and open the tables and click on data to verify that the data has been loaded.

2.2 Description of ORACLE to MONGO DB Implementation

2.2.1 Extract data

* From SQL Developer SQL Worksheet execute the following command to select data from all the tables.

Example:

SELECT * FROM
<TABLE_NAME> A
INNER JOIN <TABLE_NAME> B
ON A.EMPL_ID = B.EMPL_ID
INNER JOIN <TABLE_NAME> C
ON B.EMPL_ID = C.EMPL_ID

* On the results window, right click and select export data to CSV file.

2.2.2 Import data

* Login to MONGDO DB from UMongo UI and connect to the DB. * Click on tools menu and select import from file and select the file created from the previous step and click import data. * Verify the data by executing the following command from UMongo:
Db.employee.find()