0:00 Intro
Welcome to the Cutover. I'm Katie Thompson from JAMS. If you're watching this, you don't wanna hear from me. You wanna see an actual cutover from Tidal to JAMS, so I'll keep this fast. JAMS is priced per agent starting at $833 a month, billed annually. Add jobs, the bill stays the same. And JUMP, our migration tool, is free and it reads Tidal. Darrell Walker is about to show you how it works. Darrell, take it away

0:29 The five-step migration process
So as you just heard, we have tons of experience converting customers like yourself from their current solution to JAMS. But I'm sure you're wondering, what does this process, you know, really look like? And the honest answer is that every single migration is really a little bit different, but they all generally follow this five-step process. So it really starts with an extract from your current Tidal environment. So you're gonna send us either the Tidal job definition export in CSV format from the GUI itself, or more preferably, the database tables dumped to XML. So we're gonna analyze the, the extract and get you a conversion assessment typically in five business days. And from there, we then build the migration plan itself. So this is gonna include things like the timeline, your drop dead date that you have to be cut over by, and who is responsible for each part of this process. And then we're going to convert. So we can either use JUMP, which I'm going to show you here in a moment, to perform some automated translation of, you know, many of the existing jobs and objects in Tidal into JAMS. Or if you have a more complex environment, our services team can assist in building the jobs out for you and hand you the finished product. Then once, once we have everything built in JAMS, your team's gonna validate everything. So nothing cuts over without testing and sign-off from your team. And then we'll begin cutting those jobs over into JAMS while Tidal really runs alongside until that trust is gained and established, and we've cut over all the jobs from Tidal into JAMS. So we've done many of these migrations, a very experienced team. We recently did a very complex, deeply embedded Tidal migration, for a pharmacy benefit manager, and we completed this within four months. So, nothing that our team hasn't seen before. They have done a ton of mi-- of Tidal migrations and are very experienced in this realm

2:19 What converts from Tidal
But, you know, one of the other concerns you might have is trying to figure out, you know, what's actually going to convert from your Tidal environments. And again, the answer's probably gonna be most of it. The key is that we really need that database table extract versus the GUI extract to make that happen because the table dumps just have so much more information that's gonna help us build a lot of the, additional info on the jobs themselves, just outside of the job source that those main exports from the GUI just don't contain. So assuming we have the most complete data set possible, Tidal's really in that converts most of the way automatically camp. And that's true of using JUMP as well as our services team. So obviously there's gonna be some manual review that's gonna need to, you know, finish the job out. But for the most part, we can convert things, pretty seamlessly. We've seen a lot of Tidal environments, and typically they match up pretty well with JAMS. So again, the majority of those things can be created automatically. So those are things like the job definitions, the source within them, calendar schedules, you know, some basic dependency information, your file and, and time-based triggers, some base notification settings. Some of the things here that, you know, we can get with the database tables would be those interjob dependencies, so jobs that may be related on each other, the actual information in the notifications, all of the agent data about, you know, what those systems are, their IP addresses, host names, et cetera, retry and runaway information as well. So those things are typically missing from your basic job extract from the GUI and would require manual configuration without.

3:51 What doesn't convert
So I'm not gonna pretend this is some, you know, magic solution that's gonna instantly take your environment from Tidal to JAMS, and really no other vendor in our space should say that either. There's really too many variables at play here to really be able to fully account for all the possible iterations and variations of how, you know, your users create jobs in these types of platforms. So there's gonna be things that really just don't line up one-to-one and, you know, we have to create some items by hand or maybe we have to rework certain jobs to fit the way that JAMS handles those same scenarios. So those things could be, you know, maybe complex dependency chains, custom scripting logic that's maybe embedded in Tidal-specific constructs, really anything that's gonna require business logic interpretation. So think things like loops, if conditions, right? Things that are gonna make a task branch some way versus another, based off of an exit code or status. So some examples of things that Tidal does, that Tidal does that don't convert, would be calculated variables. So Tidal is actually calculating some value at job runtime, and while JAMS could do some of this, not all those cages-- cases, again, are gonna line up cleanly, and we have to build some workaround sometimes. So some items, may also have to be renamed because they have unsupported characters we need to strip out that aren't allowed in JAMS. And occasionally, certain scheduling conditions for things like biweekly or every N number of weeks, those may be based on a certain start date that we don't have. So we have to make sure that those timelines, are aligned as we build these jobs out. So that's kind of roughly that 25-ish percent, of items that, you know, our team and your team are going to work through together to, to make it a successful migration.

5:33 What JUMP is
So to assist with some of this stuff, we did build a, a tool called JUMP. So really, designed to be a, a free standalone tool, calling it the JAMS Universal Migration Platform, and it's designed to convert, you know, those job definitions from your existing scheduler into JAMS-ready jobs. No risk for you to use and try this out. It doesn't require a c- live connection to JAMS to test out. Nothing's migrated. We can do a dry run and just really preview the, a report of what would happen. So, very low commitment here to be able to just come in and see, you know, what would this look like if I tried to run my jobs in JAMS and migrate them.

6:12 Dry run demo
But let's go ahead and actually see what this looks like, you know, in action. So let's pop over to the JUMP tool. And here we are. So we have a number of different other sources we can convert from, but obviously, we're here to talk about Tidal. So within Tidal, I mentioned we have two ways to actually get the extract data. So we can get the CSV data, which we require the export file for the jobs, but additionally, we may ask for a variable export of a calendar export file because that's gonna help us build a more complete job set. We're gonna be missing some data about the, the triggers or information in the source of those jobs without all of this information. But, really just to give it a test and go, the job export is all you would need here. But again, we have the, the database table dumps that go to XML file is the preferred method. It's just a much more complete set, so that's what I'm gonna utilize here. So we see all of my XML dump files. I can select them all, and we can see all the ones that were recognized and imported successfully turn green, and we can import these now and take a look at 'em. So we can see all of the jobs that are in that extract. We have a hundred and sixteen total jobs. Nine of them contain warnings, no errors, and five variables we have to be concerned with in this particular extract. And we can see all of the jobs here in our list. We can select, deselect the ones we may want, so if we don't wanna convert all of the jobs, we don't have to. We can also see the information about them, like the name, the job type they're gonna convert to, basic scheduling information, their folder, the agent that they run on, and then any sort of informational messages or warnings. So this one has a template variable reference that we just wanna make sure converted into JAMS correctly, so it contains an informational message here. And then this also has a warning about an event action. So we actually were missing a table in this extract, for the, the actual events, so we don't… we didn't create it, but we know it exists based off of the job export. So we just gave you a warning that this job is going to be missing that piece, and we're gonna go have to go back and recreate it. So again, we can go through and select whichever ones we may want, so we can look through the list and see where any issues may reside. And then when we're ready, we can go ahead and continue on. The next page is where we configure the target settings for the JAMS instance. But because we wanna do a dry run, we can simply go ahead and come down to the bottom, make sure our dry run box is checked, and this isn't gonna actually write anything into JAMS. We're simply gonna validate and report on what would happen. So we run our dry run. It's gonna be very quick, see a quick output of how many of these would succeed, how many we're gonna skip, how many failed, all of the supporting objects like folders, agents, credentials, connections, variables that we're going to create alongside of these jobs. And then we can download some different reports and log files to just verify and see in more detail what happened. So we can download our HTML report here just to get a quick example. And yeah, just a, another view to see how this would've, would've progressed. So we can see again how many jobs, how many succeeded, how many skipped, how many would've failed, all of those supporting objects again and their counts. And then here's where we have all of those manual steps. So this is broken out by job, so we can see here, the bank file send job has two items. The first is informational, it's in gray, and this is about an FTP job. It has a file transfer, connection, essentially. And we just need to verify that the source and destination information in the connection is set correctly. So, just again, a verification because things like connections and credentials often don't contain some of the more, sensitive data like passwords, right? IP addresses, sometimes things that are missing. Just have to go back and verify that. And then additionally, this one was missing an event because, again, we didn't have that, specific table dump in our extract to recreate it. So this is again, the types of things that we're going to be looking for. If we look at a couple other ones here, we have a schedule trigger that couldn't be created because we were missing the calendar for it, execution method that we couldn't resolve, so we created this, we weren't able to, create this in the correct method. So we can again go through this list and see on a per job basis, you know, all of the various things we need to do, whether that's warnings in yellow or just informational, you know, check this out, in gray. And then towards the bottom, we're gonna have just a regular, table just with all of the data about this particular run. So this is, filterable and searchable if we need it to be. But again, just another view to kinda see all the jobs, where they were gonna go and any sort of warnings or informational message with them. So that's the dry run, right? Again, free to utilize, free to check out, doesn't require any commitment other than extracting some information out of your existing system.

10:56 Running a live migration
If you would like to go ahead and go through and attempt a migration with JUMP, that's also something that you can do either on your own or with our assistance, and it looks basically the same. So we're gonna come in here, and we're going to open up the Tidal section again. I'm going to choose my database tables from the list. Open. We import them. I'm gonna go ahead and leave all of my jobs selected, so we'll continue But in this instance, I'm going to uncheck my dry run box because I wanna go ahead and write into JAMS. I put my URL for the JAMS host I'm trying to connect into, and this is gonna utilize the rest API service on the back end, so we do need an API token. And I can paste that in here. When we test our connection to make sure that we're able to authenticate correctly. And then we have a couple optional fields. So the first is a target folder prefix. So what this is going to allow us to do is rather than sticking the folders that we're going to create, right, the folders you have in Tidal directly underneath the root directory in JAMS, we have the option to put a folder prefix in front of that. So-- or a parent folder in front of that. So maybe we have only selected our dev jobs, for instance, or a certain subset of jobs for a certain department. I can prefix that with whatever that might be. So I'm gonna use, in this instance, the, the company name of the, the fictional company that we are migrating here, which is Northwind. And now it's going to create that parent folder underneath roots, and then all the subfolders will spawn and be created underneath this parent directory. So just another way to be able to organize things on the fly as we're moving things over. And the second piece here is for overrides. So as we migrate things from one s-source platform to the next, we may not want to keep things like the server those jobs are being ran on or the credentials being used. Maybe we're going to move those into different systems as they're being migrated. So this is what this allows us to do. We can take whatever the values were in those extracts for the agent those jobs are running on and the credentials used to run them, and we can override those with a different value. So I could say, this is the agent I want all my Windows jobs to run on for this, this conversion, and this is the credential I want to utilize, and the same on the Linux side. So again, just kind of a, a, a nice feature to be able to modify things on the fly as we're migrating. And then the key piece down here, by default, it's gonna disable all those job triggers when we import them, right? We don't want to have these jobs firing as soon as we create them, causing all sorts of problems. So we do create the jobs, we create the triggers on them, but the triggers themselves are disabled, so they're not gonna fire and execute when we don't want them to. And then we import. It's gonna take just a minute or two here to, to import the jobs. We can also stop it anytime we need to if we realize we made a mistake. Also if we're curious, there is help documentation up here in the top corner, so basic getting started information about how to use, the JUMP tool itself, configuration, getting an API token, all of that type of stuff here. Information about, you know, what may convert, what may not convert. Specifically here within the Tidal section, we can look at that for Tidal specifically. You know, what type of things do we need to get for our extract? How do we get that information? So the list of the database tables we're interested in and commands to run to get that. Things that we're going to convert, things that are only going to convert if we get the database dumps, and then what may not convert or - what might require some manual intervention. And then again, just some gotchas and things to be aware of down here. So, trying to help you guys along the way as much as possible. And back, back here we see that everything was completed. Again, we can view that HTML report if we want to, but we can go ahead and just hop over here into the JAMS client. And let me go ahead and sign in

14:36 Checking the jobs in JAMS
And we come into the jobs tree, and we can see our Northwind folder that was created. Within that, we had all of the sub-folders for those jobs that were built underneath it. So we see our data warehouse nightly load folder. We see all of the jobs that we created, some Unix script jobs, some SQL command jobs. We can open these up and just verify things were built as we intended. So we got the job name, we got the description, the type, the source we're calling, the shell script with some parameters. Here's the scheduled information. So here's our job trigger that we had that's disabled currently. All of our dependencies we may have, job statuses like runaway conditions, and our events and notifications as well. On the properties tab, we can verify we have the correct agent set. If we had any sort of queue defined or retry information, we can add that. And then the execute as being the credential that we created to execute these jobs on our agent. If we had any parameters or variables we needed to, to, bring over, those would also be displayed here on the parameters tab. So again, trying to make this, an easy process. Obviously, you know, again, we're not going to claim this is a, a magic tool, but can help us get some of this process automated, and then, you know, our services team is definitely here to help you along the way. So again, this is a, a very great tool, but sometimes, you know, we recognize it's not a, a one-size-fits-all solution.

15:59 Services, fixed bid, and training
So every customer's gonna be different. Everyone has different skill sets, different levels, different needs, different timelines. So we're really here to be your partner through this process, and we do offer professional services that can really assist you with your migration in a more hands-on fashion. And that could be all the way from, you know, some basic help in the beginning and letting you take it from there, showing you best practices, all the way through us doing the work for you, essentially of building everything out. You verify, and we go from there. So all migrations with us are gonna be fixed bid, so the number you approve is what you're going to pay. Some environments even qualify for a free migration. Training is also always part of our migration services. We're not gonna leave you high and dry. We're not going to throw these jobs into JAMS and walk away and tell you, you know, "Here you go." it's really important to us that you understand how the solution works, you're able to work in it day to day, you're able to troubleshoot when needed, and obviously, you're able to, to know who to contact and when if you do need some additional assistance so, .

17:01 Two ways to get started
Two ways to get started here, right? If you, if you want to try it out, you can download JUMP today. You can bring your own extract. You can run it through the dry run and get a good idea of, you know, how this may look if you were decide to migrate those, those jobs to JAMS. Additionally, if you want more information about JAMS itself, feel free to schedule a live demo with us. You know, we can give you some initial pricing there. We can evaluate your use cases. We can get into more detail about, you know, the migration process, what your jobs may look like on the other side. So, happy to talk to you and, and see how we can help you guys out.

17:35 Wrap-up
That's a cutover. Every environment is different, so here's the next step. Download JUMP and run it on your own jobs or book time with our team. Bring your job count and your renewal date. Links on the screen. Thanks for watching