SC3 to SC5 the HARD way. (long)

[tommy]

We have just finished upgrading to SC5.0.1 from SC3SP3. And we moved from MVS to UNIX.

We did not use Peregrines upgrade utility we reimplemented everything on SC5, a process we started on around june 2002.

The biggest problem doing it this way is data. Not many helpdesks would accept to start on a completely empty call/problem database. They expect at least to see open calls and problems.

So I had to figure out how to move data from a MVS based SC to a unix based SC.

We decided to transfer all change records because the number of records was less than 1000. We only transferred calls in open callback or open idle status, and we only transferred open problems. And off course we transferred supporting files such as contacts, company etc.

Ok, now that we knew what to transfer we had to find out how to do it.

Even with all its bugs Connect.It was the best tool to do this with. I have on a number of occations recommended CIT and this is another.

In the follwoing list I am going to leave out details about change management because that part was handled by a co-worker so I only have the overall picture of that.

I determined that I would need to transfer following files when we wanted to do the cutover:

• operators
• contacts
• assignment
• company
• incdents
• problem
• change management files
• screlation

The sequence is important in order to take advantage of some new features in SC5. F.ex. screlation, when adding a record to the screlation file SC automatically checks if the related records exists and what state it is in, then the active fields are set according to that.

The same goes for assignment groups. In SC5 the assignment groups for a user is also stored in the operator record. No matter if You add a new assignment group on the operator record or adds the operator on the assignment group the other file is automatically updated. But since SC3 only store that information on the assignment group it is important to move the operators first.

As mentioned I used CIT to move the data. I created the corresponding input events on SC5 for the above listed files. On the input event for calls and problems I specifically included incident.id and number on the event because that way even though event services performed an open the original numbers from sc3 was kept. The same applied for changes.

Then I created a scenario, I added 2 sc conectors and added the mappings. When I started my testing I ran into a few problems.

The first problem was when I started with screlation it looked like axces.database in sc5 could not handle logical values correct because when I looked at the result in screlation the active fields looked like they were set randomly. But at this time I did NOT know that SC would checke for the related records and set those fields. Peregrine actually was able to tell me that when I reported this as a problem

The next problem occured when I transferred calls. Dates - when do Peregrine learn how to handle date fields properly? In the first tests I ran I could not set the open.time to be the exact same open.time as in SC3. This would indeed be a problem for reporting. The same thing for update.time. To solve this I added a text connector to the scenario, this text connector would write out just the number and the data fields I needed. Then I could import that file with the textfile import in SC5 and that way set the open.time correctly. I also prepared a text file for problem because I saw the same thing happen here.

Now I had all planned.

Saturday 28/12 came and we started. When I moved calls I noticed that now the open.time was set correctly so I did not need to use the text file? Very weird but I was happy, the same occured for problem.

When all data were transferred it was time to check that everything was ok. We had to run some mass updates. As for change records every single one had to be updated manually in order to set approvals correct.

In total 3 persons used 15, 15 and 10 on saturday. On sunday we used 9, 9 and 7 hours. A total of 65 hours.

I hope You can use my experience and please feel free to ask if You have any questions. I would not be surprised if this way of doing a sc3mvs to sc5unix upgrade is a first.

[imcclell]

We did almost exactly the same thing you did. We did ours the weekend before Christmas. There are only two of us (one to develop and one to be DBA) and it took us roughly 16hr each to setup the new implementation and port the data over.

The major problem we ran into was tonight ( a little over a week later) when we discovered that the page numbers differed from problem to probsummary. It left our probsummary table FUBARed. It's taken me a little over 10 hours to get things straightened up again. Did you run into the same issue?

[tommy]

No, I only moved pages with following query "last=true and flag=true"

[Maggie]

Tommy,

Nice tips here! Am interested, going from 4.03 to 5.x(?) and have the same problem of trying to keep as much data as possible for history-reasons (and ofcourse open/active items).
You wrote "In the follwoing list I am going to leave out details about change management because that part was handled by a co-worker so I only have the overall picture of that. "

Our shop wants to have a 2 year history of changes for legal reasons. Ofcourse i can store things somewhere else, but would very much like to have old data in my system, so 'reporting-people' don't have to merge two sources to give a years overview to our mgmt, and thing like that. And we are really going to do thing another way, so other forms, other flows, even other products (Intraflow maybe)....

This co-worker you talk about, do you think you can get some details from him about the things he coped with during this upgrade? Anything would help!

thx in advance,
Maggie

[tommy]

The biggest issues was with dates and arrays.

Do You have a strategy in mind? Are You going to reimplement or upgrade?

[Maggie]

reimplement. for sure, not only because of intraflow, but also because our tailoring was never documented, and i wasn't around all the time (got the job somewhere inbetween), so don't understand it all, especially Change Mgmt is hard, although I'm getting to get the hang of it.... But thing don't always work as we expect, and support couldn't help us as well.
So we start all over again.

It does'nt have to look nice in SC5, just want the most obvious data to be there, requester, dept, description, status, assignment etc... so at least we're still able to report about (or search for) something...

We probably have to resubmit all the open changes, and there are about 200-300 open recently, so.... someone suggested having two systems runnig apart from each other... that will nót work, or at least will result in my phone ringing constantly and leave my mailbox full with complaints:-(
So if there is a way, ..... I would like to know...

[tommy]

Do You have Connect.It ?

What we did was to read from the old sc and submit an event to the new sc. The difficult part is then to set the open dates properly. You may have to do an text export/import to accomplish that part.

[Maggie]

Yes, we do have Connect IT. Not for long, and I don't know how to use it yet, came in with the Asset Center project we just started here....for now only our 'external forces' know how it works...

talking about connections, any experience with, what do they call it, distributed databases (there was a nice term for it, i forgot), the ability (finally) to communicate directly with external sources (without ConnctIt) ?? Opinion? Ideas?

[fid509]

Hi Machteld,

The term you are searching for is "federated databases". As always it is just a fancy word from Peregrine witch uses the OAA (Get-It) technology to make the connection to other databases. In other words, complicated to set up and slow in performance :wink:

Geert

PS: Didn't we met when you, Pieter, Michel and I followed our SC bootcamp a few years ago?

[Maggie]

No, we havent met, unless you're from John Raemaekers course in Belgium? Is it the same Geert?

Ja, nu ik de andere namen zie, volgens mij zijn we dezelfde club, noemen we dat bootcamp nu? Hoe is ie??

leuk dit!

And tnx for the clear explanation of federated databases :wink: