Opera to Opera

The Opera to Opera functionality allows for the ability to export and import a property from one schema into another schema. This can include the removal of a property from a multi-property environment into a single property environment, the migration of a single property environment into a multi-property environment, or the migration of a single property environment into a corporate chain environment. The above will include removal of a Property from ASP mode, or from a multi property database.

Although this tool is created to try and make the process of converting O2O as easy as possible, it will as with the DMU, is not designed to do everything that may be needed to resume operations of the target resort as it was in the original source environment. The essentials are offered to assure a fairly simple process so please note that there may be data excluded that may or may not be valid in the new environment which will have to be configured manually.

Opera to Opera will migrate from V4.0.5+ to V5.0+ or from V5.0+ to V5.0+.

The following list are some tips before starting the Opera to Opera Migration Utility:

• This utility should be started right after the End of Day process.
• Source property will not be operational during active blocks, reservations, and accounts migration. Downtime associated with an average size property's data should be less than 8 hours in most instances.
• There should be good connectivity between the Source and Target databases.
• Information about the Source and Target databases will be required, including Host, Port, Service, OXI Schema Name, and OXI Schema Password.
• The OXI Schema should be installed on both the Source and Target.
• Business date on the Target property should not be any later than the Source Property's business date.
• There should not be any transactional data in the Target property.
• OXI Interface used for the migration is the O2O_MIGRATION interface.
• When any conversion is required in the configuration for the Target property, users will not choose to migrate the property but rather will configure the Target property manually. If the Opera to Opera is used in the configuration, then the user must delete the unwanted records manually.
• If code conversion is required the target property then these should be configured in OXI manually after a connection of target and source is made thru Opera to Opera. E.g. Market code, source code conversions etc can be configured in OXI. If the conversion code group does not exist in OXI then the data set will only be available in the target schema in its original code/format. It is intended that the scope of the project only includes a code to code transfer of transactional data that does not exist in conversion codes setup.
• It is assumed that the user will create DEFAULT values in Opera for transactional transfers where the data has been deleted in the source system from OXI>Interface Configuration>Interface Defaults. This means that it is recommended that all default data in interface defaults menu option in OXI. Failure to do this will result in an abnormal amount of failed messages based on historical changes and deletions. This must be done before executing the SYNC process in O2O.
• The utility will only transfer the opening balances for checked in reservations. Residual amounts in other ledgers (e.g. package ledger) will not be migrated to the target system. The user should handle these scenarios by using other alternatives such as “Post Rate Code” after migration is complete.
• The O2O migration Downtime Processes should be started right after the end of day.
• Property should be in SYNC/Steady State before Downtime Processes are started.
• The property should preserve past end of day reports as the migrated data may not be used to regenerate the end of day reports.
• AR Accounts will be created with just open/old balance.
• OVOS Owner contracts are out of scope for this project. Thus Owner Contracts or any OVOS related functionality cannot be migrated.
• All business dates for the property should have been closed before starting Migration. The target environment, after the migration, will have all the rows (from the source) in the Businessdate table.
• If the property is involved in CROSS Property Postings, property should reconcile all transactions before Migration (inter hotel ledgers).
• It is assumed that whenever possible a cold backup will be taken on Target Schema before or during downtime procedures.
• It is assumed that every level of testing will be performed in a benign environment before this application is used on a LIVE site.
• No past financial transactional data will be migrated, hence following functionality (but not limited to) will not be possible from the application…
  • View Past Folios
  • Re-generate End of Day Reports
  • 1099 amount may not be correct for the financial year.
  • 8300 forms for in-house reservation.
  • Commission handling for in-house reservation.
  • Etc.
• O2O will only migrate selected Opera tables. Only following entities will be migrated:
  • All configuration elements required for Operating the Standard hotel. (Same as DMU)(Hotel data, room types, room, numbers, market codes, reservation types etc.)
  • Profile data
  • Reservation History data
  • General Managers Report data
  • Rate Definition data
  • Rate Restrictions
  • Package definition data
  • Block Bookings data
  • Reservations
  • Forward balance entry for checked in reservations
  • Market Code Statistics
  • Rate code Statistics
  • Source Code Statistics
  • AR accounts and balances
  • Telephone Book
  • Reservation traces, messages and Routing instructions
  • Checkout message alerts will be migrated with reservations
  • CRS Interface conversion Options

The following displays how the migration flow for Opera to Opera works.

Opera to Opera will perform the following steps during a migration:

Connection Information Gathering

1. Source property database connect string
2. Target property database connect string
3. Location where folios will be stored as a space check needs to be performed
4. Location where data files will be stored as a space check needs to be performed

Login and Licensing

Go to the Utilities>Tools>Opera to Opera Migration Utility menu option and once in the utility, you will be required to enter an Authorization Code that will be supplied by Opera Support. This will be validated against the Source or Target property, based on how the utility is setup to be ran.

Accept Property Information

The user needs to select the property to be migrated (Source) and the Target property. A new property code and name can be entered for the Target property and choose to create a new property from the Source property.

If an existing property is selected as the Target property, a check will be done on reservations, blocks, etc. so a migration into a running property is not done.

Validations

The following validations are completed before the migration will continue.

• A search for unclosed business dates at the Source property.
• A search for open account balances the Source property may have from Cross Property Postings.

Tasks Selection

Allows the user to choose the number of options/entities to be migrated from the Source property to the Target property.

• Migration Data
  1. Property Creation - Mandatory step of the Target property does no exist.
  2. Configuration
     1. PMS Configuration
     2. S&C Configuration
  3. Packages
  4. Rate Codes
  5. Rate Restrictions
  6. Blocks
  7. Reservations
     1. Preserve Confirmation Numbers - Use can select ot preserve the confirmation number, but the confirmation number may have been used by another property.
  8. Events
  9. Activities
  10. Attachments and Event Resources
  11. Reservation History
  12. Profiles
      • Only Profiles attached to future reservations/blocks
      • All details
      • Memberships
  13. Telephone Book
  14. Overbooking
  15. Out of Order/Out of Service Rooms
  16. A/R Accounts
      • Without Balances
  17. Statistics
  18. Guest Folios
  19. Cleanup of logs and temporary tables

Export of Data in XML format

1. Only Profiles related to the Target property will be exported.

Delete the Source Property

The following displays which navigation options are available based on if the processes have been ran or not:

• If any process is running (Configuration, Synchronization, Downtime, Miscellaneous, etc.), the Start, Next, Previous, and Save links are disabled. Plus all of the migration tasks Stop link is enabled in their respective screens.
• If any process is completed (Configuration, Synchronization, Downtime, Miscellaneous, etc.), the Start and Stop links are disabled and a status of Completed is displayed.
• If any process is not run (Configuration, Synchronization, Downtime, Miscellaneous, etc.), the Start link is enabled and the Stop link is disabled.

See Also

• Standard Opera to Opera Execution Process
• Initialization
• Main Options
• Authorization Code
• System Connections
• Property Configuration Options
• Property Migration Options
• Parameter Configuration
• License Code Validations
• Transfer Data Using OXI
• System Down Time
• Transfer Miscellaneous
• Backup Folios
• Export Property Data
• Delete Property Data