The Portal provides invaluable support for analyzing and handling the Events that were fired during the migration. 

The Portal remembers results and Events from iteration to iteration and provides delta indicators to signal the overall progress of the migration. The workflow functionality supports the sign-off of all the Events, that were fired. By the go-live point, the status on all events should be either that the Event is not fired anymore (status Done), or that the user assigned as responsible for the Event has given it a status Accepted

In this and the following exercises, you will have a look at the different tabs in the Portal. Especially, you will see how you can drill down to a single Business Object and see: 

  • All the Events that were fired for this Business Object
  • Links to all Business Objects on which this Business Object depends
  • Links to all Business Objects dependent on this Business Object
  • The Source Data that was extracted from the Staging Tables for this Business Object
  • The Export Result for this Business Export
  • The Target Result for this Business Object

Delta indicators

Generally in the lists, there is a delta indicator next to each count. The delta indicator compares the current count to the number stored in the current baseline. 

The indicators are:

The current count is equal to Baseline (unchanged)
The current count is less than Baseline. Green if this is good, for instance, if the count of rejected Business Objects has decreased. Red if bad, for instance if the count of Business Objects that were imported successfully has decreased
The current count is greater than Baseline. Green if this is good, for instance, if the count of Business Objects that were imported successfully has increased. Red if bad, for instance, if the count of rejected Business Objects has increased

User Interface depending on User authorization

As mentioned in the last exercise, you can see the All level in the Partition dropdown because you in migFx are authorized as a Migration Team member.

Partition users, from the business(es) being migrated, will not have this global authorization and will only be authorized to see data for their respective Partitions. 

In several places, the Portal user interface differs depending on whether you are a Team Member or a Partition User. Below, the User Interface is primarily described as you see it as a Team Member.

Differences for Partition Users are described where relevant and marked like this.

Work Level

A given Event can be processed at two different levels. Either the processing of the Event takes place in the migration team or it is delegated to users in the respective Partitions.

TeamThe Event is processed by the migration team
DelegateThe processing of the Event is delegated to users in the respective Partitions.

User State

When editing the details of a given Event, you - or a Partition User if the Level is Delegate - can change the State of the Event to one of these possible States:

NoneNo State has been setNew Events are created with this State
ResolvedSome action has been taken and this Event should not occur in the next iteration
RegressionThe State was set to Resolved, but the Event occurred anyway in the last iterationThis State is set automatically by the Portal on Publish
ActiveThe Event is currently being worked on

AcceptedIt is accepted that this Event occurs and it will not prevent a final sign-off on the migration

These are the States that can be set manually on an Event. When the Event is shown in the Events list, this State in combination with the baseline comparison is translated to a List State, see below.

Let's go through the menu items one by one. 


Shows the statistics for each root Business Object in the latest migration iteration.

As elsewhere, the Partition Box allows you to see the statistics aggregated for the entire migration or for each partition. The list can be exported to an Excel spreadsheet.

The label of each column should make it clear what the column signifies. 


Shows the values that were in effect for the Runtime Parameters during the latest iteration. The Runtime Parameters are the Constants from the Studio that were marked as Runtime.


The Events tab shows an aggregated list of Events. The aggregated counts reflect your selection in the Partition Box. You must select both a Partition (or All) and a Track before the list shows anything. 

You will find that this list is extensively used and is the major entry point once you start to analyze specific events. The columns are:

Business ObjectThe Business Object that fired the Event
EventThe Event code from Studio.
CountThe number of Events that occurred in the last iteration. The count changes with the selected Partition. Clicking the count drills down in the aggregation for the Event. See following exercises.
ItemsThe number of Items that is affected by the Event. Given that the same Event may be fired more than once for the same Item, the Item count may - but does not have to be - lesser than the Event count.
SeverityThe Severity of the Event.
StateThe state of the Event processing. See below for more about this State.
AnchorThe person in the migration team keeping track of the processing of the Event. The exact meaning depends on whether the Level is Team or Delegate:

TeamThe Anchor is responsible for the Event processing
DelegateThe Anchor ensures that the Event is processed by the users in the respective Partitions

For Partition users, this column is labelled User and will show 

  • the Team Anchor if Level is Team
  • the responsible Partition User if level is Delegate.
AreaThis is the Receiver from Studio. Studio Receivers are Source, Migration and Target.
Level/DerivedIndicates if the processing of the Event takes in the migration team or is delegated to users in the respective Partitions and if the Event is derived (caused by) another Event

The processing of the Event is delegated to users in the respective Partitions
Event is derived from (or caused by) another Event
MessageThis is the Events message text with space holders in the Language chosen under the Settings tab. Clicking the Message takes you to the Event detail, where you can comment, change User State and delegate the Event.
Commentsif there are any Comments on the Event, an image will appear in this column. Hovering over the image will display the comments.

The List State

The State shown in the Events list is not the User State set on the Event, but rather the User State in combination with with the baseline comparison. The translation assists in getting a better view of the actual state of the Event in relation to the final sign-off on the migration. In addition, if the Level is Delegate, the list state has special meaning for Team users as the Event may be processed by several Partition Users.

List StateUser States and Comments
NoneThe Event occurs in the last iteration and the User State has not been set.

The default Level and Team Anchor for new Events can be set in the Portal Operations.
ResolvedThe User State has manually been set to Resolved. If the events occurs on the next iteration, the Portal Operations will automatically change the User State to Regression.
If the Level is Delegate and all Partition Users have either Accepted or Resolved the Event, any Team user will see the List State Resolved.
AcceptedOccurrences of the Event are acceptable and will not hold back a final sign off on the migration.
In ProgressResolution of the Event is in progress.
RegressionIs automatically set by the Portal on Publish, if the User State was set to Resolved and the Event nevertheless occurred in the last iteration.
The Waiting list state only occurs for Team users and only if the Level is Delegate.  Waiting means that the team is waiting for the Partition Users to resolve the Event.
DoneThis list state means that the Event did not occur in the last iteration, regardless of the User State set for the Event.

However, if the Level is Delegate, any Team user will see the list state Resolved or Waiting regardless of the actual count for the Event and it is up to the Partition Users to resolve the Event.


The Translation tab shows the Valuesets from Studio that were marked as Translation.  The Portal displays the Valuesets depending on what has been selected in the Partition dropdown.

Partition All

Shows a list of the Valuesets:


Remember, the All Partition level is only available if you have the necessary authorization. 

From here, you can:

  • up and download the entire content of a Valueset (for all partitions)
  • lock Valuesets, so users cannot edit

Specific Partition

Shows initially a list of the Valuesets together with a matrix over the validation results (if any) for the rows in each Valueset:

migFx comes with a utility function that can export the rows for all Translation Valuesets to a file and afterwards to import a file containing validation results for each row. 

For instance, if a Translation Valueset deals with the translation of code values in the Source System to code values in the Target System, the utility can be used to validate that the code values for the Target System do actually exist.

  1. Export the Valuset rows to file using the migFx Utility
  2. Hand this file to proprietary functionality to validate the rows against the Target System and write a file containing the validation results
  3. Import this file using the migFx Utility

By clicking on a Valueset, you can edit the contents of the Valueset:


Shows a searchable list of the all instances for a given Business Object 

What happened here?

The purpose of this exercise has been to introduce the panels in the Portal relevant to these training exercises. Along the way, the notions of Level, User State and List State were explained. These all provide support for a workflow around the processing and sign-off on the Events in the Portal.

In the following exercises, you will drill down on a specific Event to see more and more detail and you will see how Event details can be edited to process a given Event.