Using the DMT to import your data will result in mis-matches between foundation
data group IDs or other record IDs and those contained in your ticketing data.
We found it to be useless for moving any data that depends on links to existing
records, since it creates new records from scratch from the spreadsheet data in
whatever order it wants, resulting in record IDs that differ from your source
server. It's like trying to take custom DTS packages in SQL Server written
against one AR Server at the T-table level, and move them to another AR Server
installed separately; none of the T-table numbers line up!
Looking at a typical HPD:Help Desk record, there are several Group IDs, several
Support Group IDs, a Person ID and a Site ID, all stored in the record. If you
use DMT to recreate your foundation and customer data, none of these field
values will connect the Incident to the correct supporting records.
We have moved all of our foundation data over from ITSM 7.0.03.009 to ITSM
7.6.00.001 using rrrchive in overwrite mode for most of it... and the links are
retained because we are slamming our 7.0.03 data over the OOTB 7.6 data (for
example, some of the Calbro data will get replaced with My Company data).
Ticketing data followed, and all of the association data appears to be working
because we have forced the retention of all record ID information. In any
table that we wanted to keep some of the OOTB data but add our custom data, we
had to export to .arx and use the Import Tool since we had little success with
rrrchive in any mode except overwrite. For example, here are the settings for
two we had to import:
GROUP:
Replace Old Record with New Record
Custom Fields - on "Group Name"
Use First Matching Request
Checked:
Make Non-Core Required Fields Optional
Suppress Filters
Suppress Field Default Values
Import Records with Too Many Fields
Import Records with Too Few Fields
COM:Company
Update Old Record with New Record's Data
(Calbro and Invention get overwritten)
Request ID
Use First Matching Request
Checked:
Make Non-Core Required Fields Optional
Suppress Filters
Suppress Field Default Values
Import Records with Too Many Fields
Import Records with Too Few Fields
One of the problems we hit was that if you install the Product Catalog and
import data when setting up Atrium Core 7.6, it brings in thousands of
companies and related data that will conflict with your custom company
organizational data, especially if you are multi-tenancy like we are and have a
lot of companies. We had to reinstall AtriumCore without the product catalog
data in order to leave room for our 7.0 foundation data, and we will add it
later.
We think we got a good move of all foundation and ITSM (ServiceDesk and Change
Management) data, as well as Kinetic Request, moving it at the table level
(just over 100 tables have data). We don't have Asset Mgmt until we get to
7.6, and our CMDB is empty, so it isn't as much data as you might have.
Kinetic Request and Calendar were also moved successfully at the table level
(37 tables), but SLM has proven harder to figure out and we are still trying to
use the SLM export-import tools. We have already found a major bug in the
export where at different patch levels of the SLM 7.1 app, different forms of a
flagword were used in the SLM:SLAAssociation form, and the presence of the
earlier one (SLM_CONTRACT instead of SLMCONTRACT) prevents the correct export
of Service Agreements and related objects. We still have to re-visit the
notification subsystem - BMC rebuilt it enough that entire tables were
deprecated, but these are pass-through tables so it may still work.
We are still working on this on our test 7.5/7.6 server, and still have to (1)
move the same data from production 7.1/7.0 server to the new production 7.5/7.6
server, and (2) figure out which tables have data that must be re-copied just
before cutover since it will have changed (tickets, work info, association
records, etc.). It is complicated by the fact that we have added a fair number
of custom fields to HPD:Help Desk, and those fields must be migrated to the 7.6
app before you can move the data. We are recording everything in a spreadsheet
as we go, and it will also be our roadmap for data to move again during the
cutover.
This is probably doing it the hard way, but our tests of upgrading last year
were all relatively unsuccessful at the application level due to BMC re-writing
modules that we had customized, plus the file folder lay down of executables on
the server is different between a 7.1/7.0 install and a 7.5/7.6 install. An
upgrade is a scrambled combination of the two, making file maintenance a mess
and confusing the plugin systems when you add modules like Asset Mgmt and they
end up trying to use different path constructs. From what I saw, I would not
want to put an upgraded app into production unless I could successfully restore
it on a server with a clean install of the 7.6. apps, among other things. We
are continuing to move forward with mapping and moving data at the table level,
instead.
Christopher Strauss, Ph.D.
Call Tracking Administration Manager
University of North Texas Computing & IT Center
http://itsm.unt.edu/
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Roger Justice
Sent: Monday, April 12, 2010 9:48 AM
To: arslist@ARSLIST.ORG
Subject: Re: Import Production Data into Test Environment?
** The DMT is installed automatically with ITSM 7.6 start with the spredsheets
provided to determine what foundation data you can export and then using DMT
import. Some of your foundation data may need to be imported without the DMT.
-----Original Message-----
From: Hulmes, Timothy W Mr CTR US USA IMCOM <timothy.hul...@us.army.mil>
To: arslist@ARSLIST.ORG
Sent: Mon, Apr 12, 2010 10:42 am
Subject: Import Production Data into Test Environment?
We are in a tough bind at this point. Thought I would throw out a bone
to see if anyone knew of an easy way to complete this action.
Here is the situation, we have a production environment of:
ARS 7.5 Patch 4
CMDB 7.6 Patch 1 (Only thing we don't have is Product Catalog
installed)
ITSM 7.0.03 Patch 9 plus compatibility path 9000
SLM 7.6
In our Test environment we want to get to
ARS 7.5 Patch 4
CMDB 7.6 Patch 1
ITSM 7.6 Patch 2
SLM 7.6 Patch 1
Our database is SQL 2005. If we use a copy of our production database
to upgrade we get error because of ITSM-DSL 7.0.03 Patch 9 gives us
error during the CMDB upgrade, which is why we don't have Product
Catalog in production. We can't upgrade to ITSM without Product
Catalog.
If we do a complete fresh install in test we are good but then we don't
have any of our foundation data. We don't really want to have to
rebuild or manually import all of that data if it can be avoided.
We have a ticket in with BMC but haven't achieved success yet.
We need to begin testing our process against ITSM 7.6 ASAP, anyone have
any ideas of the fastest way to get that data if we do a fresh install
instead of upgrading against the production database?
Tim
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at
www.arslist.org<http://www.arslist.org/>
attend wwrug10 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the Answers
Are"
_attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
