Any user of the Migration App.
This product is currently in Limited Availability. We invite any Customers interested in using the product to engage Egnyte Professional Services or their Customer Success Manager to have it enabled for their domain.
We are continually working to improve and refine Migration App. This most recent release includes some exciting features, and a substantively different User Interface. Existing users of the App will definitely benefit from understanding these improvements.
What's the biggest difference I should be aware of?
There are three major changes:
- The introduction of metacommands, which are composed of multiple subcommands. This means that the Migration Operator only has to click one command, such as Migrate Data, and the App then commences to do whatever needs to be done.
- This means the Migration Operator never needs to manually scan the source. Once you create a migration job, Migration App will automatically scan the source. Then you can just click Migrate Data. This is now a metacommand and contains all the necessary steps to optionally sanitize, then migrate or true-up your data.
- And finally, we've introduced a Skip Scan Period to minimize unnecessary scanning. The Skip Scan Period defaults to 8 hours, but can be increased or decreased by request. What this means is that if a scan was successfully completed within the previous 8 hours, the next metacommand will skip the scan.
Can I still scan whenever I want?
Yes, you can always scan the source but you don't need to unless you just want a fresh view of what's on the source.
Tell me more about metacommands
Metacommands are composed of multiple subcommands, such as "scan," followed immediately by "data migration." So the Migration Operator only has to click one command, such as Migrate Data, and the App takes care of the rest.
How do metacommands improve the user experience?
In the following table, we compare the old and new UIs for a standard migration job comprised of an initial Data Migration, Sanitization, two True-Ups and a Permissions Migration. In the old UI, it requires 13 atomic commands. In the new UI, the user need only initiate 5 metacommands and Migration App takes care of the rest.
|Old User Interface||New Simplified User Interface with Metacommands|
|Click 1||Create Migration Job||Click 1||Create Migration Job
- creates job
- scans source
|Click 2||Scan source|
|Click 3||Sanitize Source||Click 2||
|Click 4||Scan source|
|Click 5||Migrate Data|
|Click 6||Scan source||Click 3||
Migrate Data (True-Up #1)
|Click 7||Sanitize Source|
|Click 8||Migrate Data (True-Up #1)|
|Click 9||Scan Source||Click 4||Migrate Data (True-Up #2)
- scans source
- sanitizes data (optional)
- scans source
- migrates data
|Click 11||Scan Source|
|Click 12||Migrate Data (True-Up #2)||Click 5||
|Click 13||Migrate Permissions|
When you create a new migration job, if you don’t want wait for the first scan to complete, you can stop the scan at any time. When you proceed to Migrate Data, the metacommand will take care of scanning the source.
Why do I need to understand the Skip Scan Period?
Previously, the Migration Operator had to be sure to scan the source in between data migration, true-ups and sanitization. Now you never need to manually scan the source, although you always have the option to do so. Whenever a scan is needed, it is part of the metacommand.
But let's say you manually run a scan command. If you follow that immediately with the Migrate Data metacommand, there would be an unnecessary scan during the metacommand.
Similarly, if you create a new migration job, it includes a scan of the source. If you immediately proceeded to Migrate Data, there'd be an unnecessary scan.
To avoid this, we implemented the Skip Scan Period, with a default of 8 hours. So if you successfully completed a scan and you proceed to Migrate Data in less than 8 hours, the initial source scan during the metacommand will be skipped. We did this to alleviate any unnecessary time delay for unnecessary scanning, as well as minimizing the logging and compute burden on the back end.
Can I change the Skip Scan Period?
Yes, while the default Skip Scan Period is 8 hours, you have the option to that it be modified. You may change it to as little as zero, and up to 24 hours. Simply submit a ticket to firstname.lastname@example.org.
Why can't I find the Sanitize command?
Sanitize is now part of the Migrate Data metacommand. So you will be given the option to sanitize every time you initiate Migrate Data. However, we introduced some intelligence into the App. So even if you do opt in for sanitizing, if nothing needs to be sanitized on the source, Migration App won't waste time trying to do so.
If you don’t want to change file names on the source, do not opt in for sanitizing. But be advised that if you don't run sanitize, those offending files and folders will NOT be migrated and you will have to handle them manually.
What's this about Job Limits?
We have implemented limits to job size and number of files that can be migrated with a single Migration Job. The limits are quite liberal, but are designed to keep Migration Operators from getting into trouble with overly cumbersome projects that could more efficiently be handled in smaller batches. We strongly recommend sizing your jobs at less than 2TB and 1M objects. Many larger migration jobs have been successfully completed, but they do take considerably more time.
What if I receive a Job Limit error?
Your options are clearly laid out in this knowledge base article: Maximum Migration Job Size.
Why does Migration App check for canonical differences?
If there are canonical differences between the source and destination, you can experience unintended data duplication or data deletion. To avoid that, Migration App now checks for canonical differences during data migration. If there are differences, we terminate the command and display an error message directing the Migration Operator to a knowledge base article.
Why does Migration App abort jobs with more than 50K files in a folder?
If a scan detects more than 50,000 files in a folder on the source, it fails the scan command and displays an error message. This is in keeping with the limitations of the Egnyte Cloud itself. Previously, a migration job containing a folder exceeding this limit would simply stall, and the user would be left to muddle through the root cause. Now we abort the job and provide an error message to explain the issue, as well as pointing to a knowledge base article on Best Practices for Creating an Egnyte Folder Structure.
Questions? Feature Requests? Other Feedback?
If you have feature suggestions or requests, feel free to submit them here and mention Migration App in the text.
For more complex requests that would benefit from providing screenshots or other attachments, you may submit them to email@example.com. Be sure to include Migration App in the email title. Our Support team will push your comments to the Product team for consideration.