Three possible viable approaches: 1) TDB conversion approach. Read in TDB dump out LDIF (one-way) - samr.ldb: from tdbsam/smbpasswd, account_policy.tdb, secrets.tdb, group_mapping.tdb, idmap.tdb, privilege.tdb - registry.ldb: from registry.tdb - wins.ldif: from wins.tdb/wins.dat - smb.conf/ea's: generated from the old smb.conf + share_info.tdb (one-way upgrades can be done by using ldbsearch -a on these dynamically generated ldb's) Since TDB's are local, there isn't much point in writing back backwards compatible data. 2) samr "mapping" backend (alternative for samr.ldb) (two-way) This would allow users to keep mixed domains containing Samba3 and Samba4. 3) The vampire way of doing things (one-way) - samba3 pidl backend - Samba4 vampire + server side samsync support in Samba3 - unixinfo (\unixinfo) - in Samba4 (client side) - in Samba3 (server side) - winsrepl (thru seperate pipe?) - enum/add shares (\srvsvc) - enum/add registry (\winreg) - enum/add printers (\winreg, perhaps also \spoolss(?)) - convert smb.conf (using Jerry's registry hack) (going with a combination of 1 and 2)