For example, when migrating a document that has been approved in the legacy system you should set the state that correctly indicates its approved state. The business object you create should also have the actual date/time of the creation and/or modification of the legacy data, and not the system generated date and time (that would reflect when the data was migrated). In some cases, you might want the business objects to act as a placeholder, representing the actual objects in the external system that is constantly changing. You can update the business objects on a regular basis by resetting the current state as well as the start, end and duration values of the states. Modifying a business object this way avoids the need for promoting the object through the lifecycle, which would result in each state reflecting the date of the import/promotion and not the date from the legacy system. Each of these (current state, start date, end date, and duration) can be changed independently, with no effect on each other. If you want to maintain these values to be consistent with each other, you must change them all. There is no impact on the lifecycle of these objects if these values are not kept consistent, except for queries that depend on these values. For more information, see MQL Command Reference: Adding Legacy Data. | |||||||