When migrating from one domain into a new one or joining multiple domains together, it can happen that a large number of databases need to be migrated across. For more than ten or so databases it can become very time-consuming to manually create all the replica stubs, even with a scheduled replication taking care of the database population. Fortunately, the Create Replica function can be configured to work as well cross-domain as it does internally to one.

There are a number of higher-level server communication-related items to verify prior to configuring the AdminP or individual databases:

  1. The two servers are cross-certified
  2. They each have server access to the other
  3. The origin server has database creation privileges on the destination server
  4. The two servers have connection documents to/from each other with bothreplication and mail routing active
  5. Running a trace from each server to the other works successfully (Note: theresults of this command on the origin server console should notify you if there are any additional requirements, such as a copy of its server doc needing to exist in the destination server’s names.nsf that we otherwise will not cover here).
  6. That the mail router is running on both servers and also that the Administration Requests mail-in database delivers to the admin4 on the destination server (or that it will successfully route to whatever its destination server is and can be easily replicated once mail is delivered)
  7. Your Notes ID, the Destination Server, and Origin Server are all in the ACLs (preferably explicitly) of the databases you wish to migrate. These entries can be removed if necessary after the migration.

Part 2: Setting up outbound

Open the admin4.nsf on the origin server, then open the Cross Domain folder, then open Configuration. Click add configuration to create a new outbound admin4 config doc. On the Configuration Type, set the type of cross-domain configuration to Outbound. On the Outbound Request Configuration tab, enter the destination’s Domino domain, check Create Replica in the drop-down for List of AdminP requests to submit, specify the destination server name and domain, and enter the origin server in the List of approved signers. Then save and close the configuration document.

Part 3: Setting up inbound

Open the admin4 on the destination server, then again open the Cross Domain folder, open Configuration, and click to add configuration. On the Configuration Type tab this should now be set as Inbound. On the Inbound Request Configuration, enter the origin server’s domain into the Receive AdminP requests from domains field, check Create Replica in the List of AdminP requests allowed from other domains, enter the destination server name as the intended server, and then enter the origin server in the List of approved signers. Save and close this document.

Part 4: Generate the requests

Generate the create replica requests on the origin server as as you normally would. Be certain to specify the full name (including org) of the destination server. Run a “tell adminp process all” on the origin server and you should see the processes handled and then routed to the destination server. Check the admin4.nsf Errors -> All Errors by Date, Cross Domain -> Delivery Failures views and the mail.box for adminp or delivery failures.

Part 5: Finish generating DBs

Open the destination server’s admin4.nsf (or replicate with the server to which they’d delivered then open) and you should now see the requests under Requests – > All Requests by Action. Run a tell adminp process all on the destination server, then check that admin4’s Errors -> All Errors by Date and, if there’s nothing problematic, you should then be able to start replicating immediately, after which you can remove any ACL entries added in part 1 if/as needed.

Check out how to Migrate Databases And Create New Replicas in this article Prominic wrote for you.