A policy engine generates configlets that are vendor-neutral, vendor-specific or both, based on a selected target level and a selected device/device group. A translator translates and combines the configlets to form vendor-dependent configuration files. The policy engine generates the configlets using policies associated with the selected target level and its sub-target levels, as defined by a target level hierarchy. A policy includes at least a condition, and an action which the policy engine performs if the condition is true. In performing the action, the policy engine typically writes to at least a partial configlet. A policy may further include a verification clause, which is used to verify a running configuration. Policy dependencies may also be defined such that where a second policy is dependent on a first policy, the second policy must be evaluated after the first policy. This is necessary, where, for example, the first policy generates and stores a value to be used by the second policy. Policies are small programs written as small programs. A configlet hierarchy is defined, such that a child configlet inherits properties which it does not define from its parent. A mapping function maps infrastructure data in a first format to a second format, so that the second format is recognizable by the policy engine. A loader batches, schedules and loads a configuration file to its intended device. Upon replacing a first device using a first configuration format with a second device using a second configuration format, the first device's configuration is read in or uploaded and reverse-translated into configlets. The configlets are then translated into a configuration formatted for the second device. The system retains device logins and passwords in encrypted format. A user desiring to connect to a device must log in to the system instead. The system in turn logs in or connects to the device and passes information back and forth between the user and the device, as if the user were logged directly into the device.