Following is a simple example of a typical development cycle using a LANSA for i Master System with a Visual LANSA Slave System:

• System Initialization is used to prepare a newly installed Visual LANSA Slave System. The initialization will copy the system definition data along with user and task details from the Master System to the Slave System. This step is typically performed during the Visual LANSA installation.
• System Initialization is also used to create a matching partition in a Visual LANSA System. For example, if the LANSA for i has a TRN training partition, the matching TRN partition is created in Visual LANSA using System Initialization.
• When a new partition is defined in Visual LANSA as part of the System Initialization it must be followed by a Partition Initialization to prepare the new partition for use and perform any required standard imports into the partition.
• Repository Synchronization is set up on the LANSA for i Master System so that any changes to objects on the Master System on the IBM i will be automatically propagated to the Visual LANSA Slave Systems.
• A LANSA for i export can be created to move a group of objects from the LANSA for i Repository to the Visual LANSA System. This is particularly efficient when dealing with large numbers of objects. (Refer to Import.) 
• If a developer intends to modify an object in Visual LANSA, the object must be exported or checked out for update, and will be locked to a task and to a PC.
• A developer will logon to a partition in Visual LANSA using a Task ID. The developer can update any objects that have been checked out for update with the current task to the current PC. The developer can create objects in Visual LANSA. The developer can view, compile and use the read-only objects in the repository, but read-only objects cannot be changed.
• If a developer wants to modify a read-only object, the developer must 5.5 Check Out the object for update from the Master Repository.
• The developer can 5.6 Check In new objects and any updated objects to the LANSA for i Master System so that other developers can access the new objects and/or updated object definitions.
• When a change is made to objects in the LANSA for i Master Repository, Repository Synchronization can be used to ensure that the Visual LANSA Repositories remain synchronized.

It is important to note that the following from this example:

• A Visual LANSA System may only have one partition but the LANSA for i Master could have multiple partitions. Visual LANSA must be initialized for any partition where you want to do development with Visual LANSA.
• If system or partition definitions are modified on the LANSA for i Master, system and/or partition initialization may need to be performed again.
• The Visual LANSA Repository does not have to be a complete copy of the LANSA for i Repository. You can export any number of objects from the Master System.
• If you are using Repository Synchronization for a Visual LANSA System, then the complete object lists for the partition will match and system information will constantly be maintained.
• If you are not using Repository Synchronization, naming standards must be strictly adhered to, to avoid duplicate objects being created on Slave Visual LANSA Systems.