Now Up-to-Date Full State Migration

Sooner or later we get asked about everything.

We got our first inquiry about Now Up-to-Date (NUTD) a few years back, when I thought they like every other software company who hitched their wagon so tightly to Apple had been rendered into Elmer's and Alpo. Since the inquiry involved all of twenty users, we just ignored it. Turns out Now is still around (though the move from Oregon to Ohio must have been pretty traumatic).

Our second inquiry just came in a few weeks ago, and since it's only a few hundred users we're going to ignore it as well. But being as how the decryption team has been itching for something else to do we started wondering "What is so hard about migrating NUTD?"

Our conclusion:

Full-state server-side-only migration is not possible with NUTD.

First, keep in mind, when we say migration we mean a server-side full-state migration, touching the client side not at all: user lists, recurrence patterns, guest responses, basically as much information as it is possible to extract.

Everyone on the fora we see seems to be in a dither just getting client-side to client-side migration to work. We'll show you why that should be simple if you start writing your own scripts.

So here's the quick sketch of client-side data availability in NUTD.

First point: The server contains way less info than other calendar systems (by which I mean Exchange, Oracle, GroupWise, Lotus Notes/Domino, etc.), so look to the client as the most promising avenue.

Client Side Analysis

So client side let's see what kinds of export options we have. Don't get your hopes up. There aren't many. I'm doing this on Window, and I see from the documentation you have a few more template options on the Macintosh, but the data fields are the same.

And these are pretty much all the options you've got -- your only choice is order, and whether to take them or ignore them. Let's work with the defaults. An export of 1 standalone appointment, 1 meeting, and 1 repeating appointment (which I erroneously called a meeting in the screenshot) results in the following text file (split for ease of viewing):

There are very few surprises here. You have the date of the appointment, the start and end times, the title, notes, categories, and priorities. You can clearly read this into any spreadsheet of your choice and order / manipulate the data into something that almost any other client will accept. If you need iCalendar that will require some more work but it's computer science, not rocket science.

1. This format strips all recurrence patterns and leaves recurrences as individual instances - the usual default in client-side exports (in Oracle Calendar migrations we need to re-create those, which we don't recommend you try on your own - it took us a few months to get right)


2. This format strips the guest list - which is pretty much the rule in client side-exports, but still fairly unforgivable from an end user / synchronization perspective: WHO you are meeting with is just as important as WHEN.


3. Forget meeting locations and resources since the guest list is by all appearances managed server-side. In fact it's kind of goofy the export does not include a "Location" field.


4. You need to take direct control of your time zone info


5. There's a variety of other info types which you can take or not depending on your target system. Usually banners and tasks will map well, the rest you can assign as your users / constraints dictate



6. Going into Outlook/Exchange watch out with Holidays and Banners - these are best dealt with as All-Day Events


7. Rooms and Resources - ignore these at your peril. You need to migrate those as well -- and it looks as though the best way is to have the Proxy for the room/resource view it and export it in the same manner and format as their own calendar.


8. International users: Keep an eye on the character sets, I wouldn't be surprised if there are issues for accented characters.

Next thing to notice.

Following down the path C:\Program Files\Now Software\Now Up-to-Date

I find that my data file (*.nud) is 62 KB in size, containing a total of three meetings / appointments of various sizes.

Following down the path to my server (C:\Program Files\Now Software\NSM\Servers\SumatraNUTDServer) where I have already created another user, some public categories, a Meeting Room, and a Resource, I find that file to be 4 KB in size. This size disparity between server and client speaks volumes.

Server Side Analysis

Let's look at the options available to us as server admins. Again, do not get your hopes up.

Pretty much the only thing you can do is start it, stop it, add / configure users, resources, and rooms, and a few other things. While there is an automated backup option, noticeable absent is any kind of server-side export capability (which allowed us to migrate Oracle and Meeting Maker wherever they need to go) or any tools for direct manipulation of data server-side.

So let's see what we can grab off the shelf.

First thing we'd notice is that on Windows this server file helpfully has a .DB extension, indicating that it is a database (d'oh), most probably relational (semi d'oh again - there are object-oriented calendar databases) and perhaps built with an off-the-shelf package whose judicious use of import / export and clever analysis might result in the schema and associated data structures.

Let's hold that last idea for a bit (because it will be quite a lot of work fumbling about for the right package and I already went through two candidates) and just let our ADHD selves open the server database with a binary file viewer, the curious calendar migrator's best friend. I like BinViewer.

The meeting "First Meeting" is definitely in here. I know on the client side that I associated it with Room222, Resource1, and my co-worked Russ....

... who also all exist in this database. I'll leave it as an exercise to the interested reader to determine if the Administrator passwords for these objects are in the clear or weakly encoded.

Most notably here where we see the name of the meeting in clear text and the human guest associated with it. A little additional work is required to see the relationship of the associated resource and room. Searching for the name of any appointment you created client-side comes up negative, confirming that the appointments are not present on the server. Notice I have not dug into the issue of recurrence patterns in meeting data server side yet because I already know where this is leading.

Short answer: we know the relevant meeting data is present server-side, and we know if we start coding into the bit field of a shutdown server database we have very good odds of reconstructing it.

The more important issue is: DO WE WANT TO?

We already know that at the very least we're going to need to touch every client to extract their appointments, banners, tasks, etc. Running another server-side process to get at the live meeting data sounds questionable: it's running two disparate processes where one is almost always far and away preferable, and making sure both processes jibe with each other.

Conclusion

Unless you've got a few thousand NUTD users (which is hard to believe) who all absolutely need their guest lists and recurrence patterns, stay client-side and don't spend a lot other than scripting time when you decide to migrate.