static void Main(string args[])

{

    DateTime lastMigrationDate=DateTime.Parse(args[1]);

    string siteUrl=args[2];

    string listUrl=args[3];

...

    var dbCustomers=from customer in dbDataContext.Customers

where customer.Modified>lastMigrationDate

select customer;

   SPSite site=new SPSite(siteUrl);

   SPList list=site.RootWeb.GetListByUrl(listUrl);

   foreach(var aCustomer in dbCustomers)

   {

         SPListItem item=list.Items.Add();

       item["Name"]=aCustomer.Name;

       item["DbID"]=aCustomer.CustomerID;

...

item.Update();

   }

}

και να πατήσεις F5, παρά να γράψεις τον ίδιο κώδικα σε κάποιο event μέσα σε ένα Web part, το οποίο μετά θα πρέπει να κάνεις deploy στον server, να το προσθέσεις στο Web Part gallery, και μετά σε κάποια σελίδα, να κάνεις attach το Visual Studio στο Application pool και μετά να δεις τί γίνεται. 
Άσε που το console application γίνεται εύκολα schedule από τα ίδια τα Windows! Απλά το προσθέτεις στα scheduled tasks και τελείωσες!

Αν θέλεις να δώσεις κάποιο link για να ενεργοποιήσεις τη διαδικασία και μέσα από το web site τότε έχει νόημα να σκεφτείς το web part, αν και υπάρχουν άλλοι τρόποι, π.χ. να προσθέσεις ένα link στα settings το οποίο θα κάνει αυτή τη δουλειά.

Τυγχάνει αυτό τον καιρό να κάνω ακριβώς αυτό που ζητάς (όχι με Navision) οπότε έχω ήδη βρει αρκετά ενδιαφέροντα πράγματα. Για παράδειγμα, αν η βάση έχει πεδία Modified, Created, μπορείς σχετικά εύκολα να ξεχωρίσεις ποιοί πελάτες πρέπει να γίνουν update και ποιοί insert. Διαφορετικά θα πρέπει να βρεις τη διαφορά μεταξύ πελατών στη βάση και στο Sharepoint. Μία quick & dirty λύση είναι να τραβήξεις τα ονόματα ή τα ID των πελάτων μόνο από τις δύο λίστες και να χρησιμοποιήσεις τις Except/Intersect functions του LINQ. Για παράδειγμα, η dbCustomerNames.Except(spCustomerNames) θα σου γυρίσει τους νέους πελάτες στη βάση, η spCustomerNames.Except(dbCustomerNames) θα σου γυρίσει πελάτες που δεν υπάρχουν πλέον στη βάση (γιατί διαγράφηκαν, απενεργοποιήθηκαν, ξερωγωτί) και τέλος η spCustomerNames.Intersect(dbCustomerNames) θα σου γυρίσει τους κοινούς πελάτες οι οποίοι πρέπει να γίνουν update.

Μία άλλη λύση που χρησιμοποίησα είναι η alpha έκδοση του LINQ to Sharepoint provider από το codeplex. Δεν είναι μία πλήρης υλοποίηση, αλλά αναζητήσεις σε μία λίστα τις κάνει πολύ εύκολα και μπορείς να πάρεις τα αποτελέσματα σε μορφή αντικειμένων, αντί να ψάχνεσαι να βρεις ποιά είναι τα internal names των πεδίων, πως γράφεται αυτό το ρημαδοCAML query κλπ. Το project είναι ψιλοπαγωμένο επειδή ο Bart de Smet προσλήφθηκε από τη Microsoft πριν 2 χρόνια και το LINQ to Sharepoint θα μπει στην επόμενη έκδοση του Sharepoint. Ο χρόνος όμως που μου γλύτωσε από το να ψάχνω τα queries αξίζει τις μικροατέλειες. 

Φρόντισε όλο τον ουσιαστικό κώδικα του migration να τον βάλεις σε ξεχωριστή κλάση για να μπορείς να τον καλέσεις και από το console application και από κάποιο job,  web part ή administrative page. Το ιδανικό θα είναι να μπορείς να καλέσεις από οποιοδήποτε κώδικα μία μέθοδο π.χ. Migrator.Migrate(siteUrl,listUrl,dbConnection) η οποία θα κάνει όλη τη δουλειά. 

Άλλα τινά? Logging! Φρόντισε να βάλεις από την αρχή μέσα κάποιο logging framework για να μπορείς να κάνεις logging και exception handling. Ειδικά στις batchοδουλειές ο admin του συστήματος πρέπει να ξέρεις ποιές εγγραφές πέρασαν, ποιές όχι και γιατί. Για να μην γεμίσει όμως το event log με εγγραφές του στυλ "Ο χρήστης ΧΨΩ γράφτηκε με επιτυχία" θα πρέπει να ξεχωρίσεις τί είδους μηνύματα θα πάνε που. Αυτό γίνεται εύκολα π.χ. με το Enterprise Library ή το log4net, άσταγιαβράστα όμως αν πας να το φτιάξεις μόνος σου.
Πέρα δηλαδή από το προφανές, ότι αντί να γράφεις κώδικα για migration θα επαναξανανακαλύπτεις τον ξύλινο τροχό χωρίς μεταλικά δακτυλίδια, όταν μπορείς να βρεις με την ίδια τιμή λάστιχα radial.
Και μην το αφήσεις τελευταίο όπως έκανα εγώ, γιατί θα τρέχεις να το προσθέσεις στη χειρότερη φάση, αυτή του deployment.

Αυτά τα ολίγα για αρχή, κι εδώ είμαστε. Το show έχει ενδιαφέρον!