You can use the restoreConfig and wsadmin commands to roll back a migrated WebSphere® Application Server Version 8.5 federated node to
the state that it was in before migration. For each federated node
that you want to roll back, you must roll back the federated node
itself and the corresponding changes made to the primary repository
located on the deployment manager.
Before you begin
Supported configurations: This
article is about configuration migration, such as migrating deployment
managers and federated nodes in a network deployment environment.
The Application Migration Toolkit for WebSphere Application Server
provides support for migrating applications from previous versions
of WebSphere Application Server to the latest product version. For
information about migrating applications, read more about the Application
Migration Toolkit.
sptcfg
Best practice: When migrating a Version 6.1
or above federated node, the best practice is to perform the following
actions if you want to be able to roll it back to its previous state
after migration:
- Back up your existing configuration.
- Run the backupConfig command or your own preferred
utility to back up the Version 8.5 deployment manager configuration.
- Run the backupConfig command or your own preferred
utility to back up the Version 6.1 or above federated node configuration.
Important: Make sure that you note the exact name
and location of this backed-up configuration.
See backupConfig
command for more information.
- Migrate the federated node.
- If necessary, you can now roll back the federated node that you
just migrated.
Important: If you do not have a backup copy
of your Version 8.5 deployment
manager configuration as it was before you migrated the Version 6.1
or above federated node that you want to roll back, you cannot use
the procedure described in this article and you must roll back your
whole cell.
About this task
You must perform all of the backup and rollback actions
for each migrated federated node before you proceed to migrate another
federated node.
Procedure
- Run the backupConfig command or your
own preferred utility to back up the Version 8.5 deployment manager
configuration at the current state.
Important: Make sure that you note the exact name and location of this backed-up
configuration.
See backupConfig command for
more information.
- Stop all servers and the node agent on the Version 8.5 federated node that
you want to roll back.
- Restore your previous configuration.
- Run the restoreConfig command or
your own preferred utility to restore the previous Version 8.5 deployment manager
configuration.
Important: - Make sure that you restore the same backed-up configuration that
you created just before you migrated the federated node.
- If you have made changes to your environment (application or configuration
changes for example), these changes are rolled back at the same time
and cause the other nodes to force synchronization with the deployment
manager.
See restoreConfig command for more information.
- Perform one of the following actions to restore the
Version 6.1 or above configuration for the federated node.
- Start the Version 8.5 deployment manager.
- Perform any application maintenance that is required.
- Synchronize the Version 6.1 or above federated node with
the deployment manager.
See Synchronizing nodes
using the wsadmin scripting tool for more information.
- If you chose to keep the installed applications in the
same location as the prior release during migration to Version 8.5 and any of the Version 8.5 applications are
not compatible with the prior release, install applications that are
compatible.
- Start the rolled-back Version 6.1 or above federated node
and servers.
- Validate that the configuration is satisfactory.
This is the last chance to undo the rollback action by restoring
the deployment-manager configuration that you backed up in the first
step.
Delete the Version 8.5 profile for the federated
node that you rolled back to Version 6.1 or above. See Deleting profiles for more information.
Results
The configuration should now be returned to the state that
it was in before migration.
What to do next
You can now restart the migration process if you want to
do so.