(by Karin Espelage)
We are running out of disc space – will we gain disc space with archiving?
We plan to migrate from Baan 4 to Baan 5. What should we do first - archive or
migrate?
We’ve got many customizations – how will they affect archiving?
We’re working 24/7. Can we archive while users are on the system?
Usually archive companies are set up by
year. That makes it possible to roll companies off
the system by year. For example, 1999 data is archived into company 199. 2000 data is
archived into company 200 and so on. In 2005, company 199 is deleted and the data is only
kept on tape.
This also makes it possible to reset the first free numbers after a year. Since, in most cases, it
is not possible to have the same order numbers in the same archive company, a new archive
company has to be started, if order numbers have been reset and reused
previously .
Sorting the data into different companies by year simplifies the data management.
An archive strategy should answer the following
questions:
- How frequently should data be archived?
- How long should data be retained in the
production/original company?
- How long should data be kept on-line and accessible to users in the archive company?
The requirements vary from company to company, and it has to be determined for each
company individually what the business demands are. Data must have a certain status
before it can be archived (e.g. production orders closed, projects closed).
But the following
are common
factors that determine an archive strategy:
The frequency of archiving (usually yearly or monthly) depends a lot on
order processing times . For example, if production order processing times are short
and the number of orders are very high, it can make sense to archive production orders
and related data as part of the month-end closing procedure.
which
modules are implemented and the dependencies between them. For
example,
sales orders might be closed, but they might belong to a project that hasn't been
closed
yet and therefore they can't get archived yet. Archiving only makes sense if there is
a
lot of
data ready to be archived. Otherwise, it will just make the data more difficult
to
find.
how much master data has to be refreshed for each new archiving. In big companies,
copying master data to the archive company can take a long time and make yearly
archiving the only feasible strategy.
In most cases, I recommend starting with a yearly archiving policy and, once the IT
department and the users are more familiar with the archiving procedures, consider
increasing the frequency for certain areas - if it's desirable and feasible.
The required retention time for inactive data in the production company depends a lot on
whether only standard Baan sessions are used. Baan standard doesn’t offer the possibility
to archive certain data, such as standard sales orders and sales order history. It
is, however,
necessary to delete this data in order to be able to run other archive processes.
For example,
sales
orders have to be deleted before the related integration transactions can be archived.
If only standard sessions are used and the data is not available after deletion anymore, then
it is usually necessary to retain data for a longer period of time in the production company.
For many companies, yearly archiving for data that is older than one year
+ the number of
month in the current year is a good strategy. For example, in 2002, the data
up until the end
of 2000 is archived. An archiving strategy like this is mostly only possible
if some additional
customized sessions are used.
How long data has to be kept on-line and accessible in the archive company depends usually
a lot on auditing and warranty requirements and there is no general recommendation
possible.
When you archive for the first time, you’ll probably actually need additional disc space.
You’ll build up a new company for archiving and you’ll copy the master or general data
(items, customers, MCS tables, chart of account, etc.) to this company. The dynamic data
(orders, history, etc.) will be copied to the archive company AND deleted
out of the
production company. The master data (items, customers, suppliers etc.) will only be copied
to the archive
company but NOT be deleted out of the original company. Therefore, some
data will be duplicated. (More detail here)
instead of archived.
Eventually disc space will be regained when archive companies are taken off the system
and are stored on other media, but that is usually a few years after the first archiving is
performed.
How long data has to be kept on-line and accessible in an archive company depends on the
company-specific business requirements and varies from company to company.
My recommendation is: do the upgrade first. I’ve observed significant differences between
the b and c versions in terms of performance. Of course, system performance always has to do
with a lot of components, not just the Baan version.
In general, though, archiving seems to
go much faster on c4 than on b. This can
make a big difference in companies with a lot of
data where archive procedures might run over several weeks.
Besides – if you do the archiving before you do the upgrade, you’ll have to apply all the
latest archive patches to the system for the old version. If
you do it afterwards, you should
already have the newest Baan version.
That depends on the amount of data you've got. During the migration process, all data has
to be transferred from the Baan 4 environment to the new Baan 5 environment. During this
time, the system is not available to the users. Archiving beforehand will
reduce the amount
of data that has to be migrated and will thereby shorten the time window that is needed for
the migration. The archive companies can be kept in Baan 4 as the legacy system. In most
cases, archiving before migrating is the recommended strategy.
You have to run the following sessions, before reusing first free numbers:
In addition to that, the data from table tdltc104 has to be deleted if lot tracking is
implemented. The standard session to do that is “Delete Lots” (tdltc1230m000), but deleting
lots requires you to archive/delete all the orders and history first where
those lots are used.
You might want to consider deleting tdltc104 through "General Table
Maintenance"
instead.
Nothing. Unlike other orders, warehouse orders are not only identified by the order number,
but by order number, transaction date and time. Therefore, it’s possible to re-use warehouse
order numbers and have the same order number in one company multiple times.
Customizations are usually no big problem for the standard archiving processes. The only
problem that could arise is if mandatory references have been added to table fields. That
might cause an archiving process to abort with a fatal reference error. The
referenced data
is needed in the archiving company beforehand, but the problem is usually easily solved by
copying the needed reference data over to the archive company.
If you added new tables to the system, and you want to archive the data in these tables,
you'll need to develop additional archive sessions to do that. Fortunately the development
of these sessions is mostly very easy, since the Baan standard DLL for archiving
can be used.
While customizations usually don’t affect the standard archiving processes, archiving data
might affect the output of your customizations. The effect on customizations has to be
considered and analyzed when developing an archiving strategy. You don't want
that
important report for the CEO to come out wrong all of a sudden, do you?
Yes, you can. That has also been confirmed by Baan support.
The archiving processes always copy the data to the archiving company first, and then
delete it out of the real company. The worst that can happen, if a process aborts, is that a
record exists in both companies afterwards. In most cases, you
can just restart the process.
Some archiving processes will abort upon restart with a fatal error (“Duplicate value…”).
If that is the case, you’ll have to find the duplicate record in the archive company and delete
it before you can restart.
I’ve seen data duplicated sometimes; I’ve never seen data disappear because a process
aborted…
The main problems I have encountered so far were:
all kind of data problems, which were not really archive problems but surfaced during
an archive project, sometimes originating from unprofessionally done customizations
or data migrations, but also from Baan software bugs.
system performance/runtime: some sessions run incredibly long, especially “Archive
Projects” and “Archive Integration Transactions.” That depends, of course, a lot on
the individual system performance, the Baan version and the number of
records on the
system.
Baan bugs: there used to be a lot of bugs in the Baan sessions but fortunately
Baan
solved a lot of these. It will save you a lot of trouble if you import the latest patches for
the archive
sessions before you start archiving.
missing functionality: Baan doesn't offer archive sessions for certain data that most
companies want to keep: e.g. sales order data and purchase order data.