Migrating from an existing Centos 6 based installation can seem like an overwhelming task and here is our recommendations when tackling it.
- Start by setting up a new ftrack server using the new Kubernetes based approach, but keep the old server running. Familiarise yourself with the new setup and the concepts around it so that you understand how processes are running and where logs are.
- Verify that the new setup works as expected via UI, API, and any pipeline tools that you use.
- Restore all data to the new setup including database and files, and do another round of testing to verify that everything is working as expected.
- When everything looks good on the new setup, and you feel confident about it, migrate all data again and switch over to using the new server in production.
We recommend that you have the old server and the new server both operational at this time so that you quickly can switch back to the old setup if you find that something is not working as expected.
A new license key is required for the new Kubernetes based installation, contact sales or support to get a new license.
Backup and restore method
For larger databases, we recommend using an alternative restore and backup method which is much faster than mysqldump, read more under the Backups section.
Timezones
The new setup will have timezone support enabled by default, and it should not be turned off. If you are already running with timezone support enabled you can skip this step, if not (it had to be enabled manually via the ftrack.ini config file in the Centos 6 version) follow this guide.
Converting the data between timezones should only be done once, and only when you have switched over to the new setup to avoid situations where dates are mixed between UTC and not.
In the Centos 6 based setup, all data would be stored in your timezone by default, and in the new setup, everything is in UTC by default. To move from the old setup to the new you need to convert some of the dates in the database from your timezone to UTC to avoid situations where data shows up in the interface at the wrong time.
To convert the data from your timezone to UTC you need to run the following in MySQL, where offset is your offset to UTC in minutes:
SET @offset_minutes := -120;
UPDATE `task` SET `startdate`= ADDDATE(`startdate`, INTERVAL @offset_minutes MINUTE) where `startdate` 0;
UPDATE `task` SET `enddate`= ADDDATE(`enddate`, INTERVAL @offset_minutes MINUTE) where `enddate` 0;
UPDATE `note` SET `date`= ADDDATE(`date`, INTERVAL @offset_minutes MINUTE);
UPDATE `timer` SET `start`= ADDDATE(`start`, INTERVAL @offset_minutes MINUTE);
UPDATE `timelog` SET `start`= ADDDATE(`start`, INTERVAL @offset_minutes MINUTE);
UPDATE `show` SET `startdate`= ADDDATE(`startdate`, INTERVAL @offset_minutes MINUTE);
UPDATE `show` SET `enddate`= ADDDATE(`enddate`, INTERVAL @offset_minutes MINUTE);
UPDATE `job` SET `created_at`= ADDDATE(`created_at`, INTERVAL @offset_minutes MINUTE);
UPDATE `job` SET `finished_at`= ADDDATE(`finished_at`, INTERVAL @offset_minutes MINUTE);
UPDATE `review_session` SET `created_at`= ADDDATE(`created_at`, INTERVAL @offset_minutes MINUTE);
UPDATE `review_session` SET `start`= ADDDATE(`start`, INTERVAL @offset_minutes MINUTE);
UPDATE `review_session` SET `end`= ADDDATE(`end`, INTERVAL @offset_minutes MINUTE);
UPDATE `review_session_invitee` SET `created_at`= ADDDATE(`created_at`, INTERVAL @offset_minutes MINUTE);
UPDATE `review_session_object` SET `created_at`= ADDDATE(`created_at`, INTERVAL @offset_minutes MINUTE);
UPDATE `review_session_object_status` SET `created_at`= ADDDATE(`created_at`, INTERVAL @offset_minutes MINUTE);
UPDATE `calendar_event` SET `start`= ADDDATE(`start`, INTERVAL @offset_minutes MINUTE) WHERE forecast=0;
UPDATE `calendar_event` SET `end`= ADDDATE(`end`, INTERVAL @offset_minutes MINUTE) WHERE forecast=0;
UPDATE `social_event` SET `created_at`= ADDDATE(`created_at`, INTERVAL @offset_minutes MINUTE);
UPDATE `social_feed` SET `created_at`= ADDDATE(`created_at`, INTERVAL @offset_minutes MINUTE);
UPDATE `social_notification` SET `created_at`= ADDDATE(`created_at`, INTERVAL @offset_minutes MINUTE);
UPDATE `social_subscription` SET `created_at`= ADDDATE(`created_at`, INTERVAL @offset_minutes MINUTE);
UPDATE `asset_version` SET `date`= ADDDATE(`date`, INTERVAL @offset_minutes MINUTE);
UPDATE `timelog` SET `time_zone_offset`= `time_zone_offset` + (60 * @offset_minutes);
Example: If you are located ahead of UTC time by 2 hours, your offset would be -120 and if you are 2 hours after UTC time the offset would be 120
After converting the data, inspect dates in various places in the UI to ensure it matches what you see on the old server. Examples to inspect are the activities tab, versions published, and the tasks schedule.