Honestly, I appreciate the advice. I ultimately must oversee the process so it helps to know as much as possible. On Jul 10, 2012 12:00 PM, <[email protected]> wrote:
> He could do it himself but then that is tedious and it renders the expert > jobless...give a chance to the expert to make some money out of what they > know best... > S e n t f r o m m y B l a c k B e r r y ® s m a r t p h o n e > > -----Original Message----- > From: [email protected] > Sender: [email protected]: Tue, 10 Jul 2012 03:50:29 > To: Uganda Linux User Group<[email protected]> > Reply-To: Uganda Linux User Group <[email protected]> > Subject: Re: [LUG] Data migration expert urgently needed > > But, i think you can do it, with some fine grained analysis of what is to > be migrated, what the destination system supports, and what conversions > are needed: for instance; > > For each database in source system, extract and analyze existing MSSQL > database schema plus any conversions needed for the new system ( that is > data dictionary tables, data tables, table attributes, special attributes > like CLOBS, BLOBS, Spatial, etc, Stored Procedures, Triggers, Indices, > Stored queries/views, Security schema, Integrity constraints like FKs, > Transaction logs, Audit rules, etc) > > Come then to the mid tier (if it seamlessly supports PostgreSQL, good, if > it does not, then you will have to redeploy most of the apps to the new > mid tier that supports postgreSQL...) > > Come to the client tier (if it seamlessly supports PostgreSQL, also good, > otherwise you may have to tweak with the existing client apps especially > the connection drivers and queries they use with postgre...) > > Come to the already existing backed up data (if you will not need to > convert it to PostgreSQL format, good, but if you will, then be it... ) > > With the above, you will deduce what conversions are needed (ie new > connection drivers, a new mid tier, extent of tweaking with the apps, data > type conversions, new procedures, new triggers, new indices, how to handle > the existing backed up data, the data that will have accumulated in the > window before the new system comes into play, etc, etc) > > Finally to the data bulk itself and analyze storage, bandwidth, time, man > hours, stable power hours you need, hardware, other system requirements, > etc and you are good to pump the data to your new system.... > > Of course, there are tools to automate the process but without a clear > guideline, you may have a tough fall back position amid the way when the > automating process needs urgent help from its manufacturer and likewise > when the PostgreSQL expert tells you he is sorry what you are asking for > is to be supported in the newer version to be released very soon... > > Thanks. > > > Hi all, > > > > One of my clients urgently needs to migrate a large amount of data from > > one > > system to another. Continuous one or two-way synchronization may be > > required. The DB technologies are MSSQL (source) and PostgreSQL > > (destination). > > > > This is a paying job. Experience with open-source ETL software (e.g. > > Kettle/Pentaho, Jasper) is a must. Strong communication skills are also > a > > must. Please send me an e-mail off-list if you think you can help. > > > > Regards, > > Kyle Spencer > > _______________________________________________ > > The Uganda Linux User Group: http://linux.or.ug > > > > Send messages to this mailing list by addressing e-mails to: > > [email protected] > > Mailing list archives: http://www.mail-archive.com/[email protected]/ > > Mailing list settings: http://kym.net/mailman/listinfo/lug > > To unsubscribe: http://kym.net/mailman/options/lug > > > > The Uganda LUG mailing list is generously hosted by INFOCOM: > > http://www.infocom.co.ug/ > > > > The above comments and data are owned by whoever posted them (including > > attachments if any). The mailing list host is not responsible for them in > > any way. > > > _______________________________________________ > The Uganda Linux User Group: http://linux.or.ug > > Send messages to this mailing list by addressing e-mails to: > [email protected] > Mailing list archives: http://www.mail-archive.com/[email protected]/ > Mailing list settings: http://kym.net/mailman/listinfo/lug > To unsubscribe: http://kym.net/mailman/options/lug > > The Uganda LUG mailing list is generously hosted by INFOCOM: > http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The mailing list host is not responsible for them in > any way. > _______________________________________________ > The Uganda Linux User Group: http://linux.or.ug > > Send messages to this mailing list by addressing e-mails to: > [email protected] > Mailing list archives: http://www.mail-archive.com/[email protected]/ > Mailing list settings: http://kym.net/mailman/listinfo/lug > To unsubscribe: http://kym.net/mailman/options/lug > > The Uganda LUG mailing list is generously hosted by INFOCOM: > http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The mailing list host is not responsible for them in > any way. >
_______________________________________________ The Uganda Linux User Group: http://linux.or.ug Send messages to this mailing list by addressing e-mails to: [email protected] Mailing list archives: http://www.mail-archive.com/[email protected]/ Mailing list settings: http://kym.net/mailman/listinfo/lug To unsubscribe: http://kym.net/mailman/options/lug The Uganda LUG mailing list is generously hosted by INFOCOM: http://www.infocom.co.ug/ The above comments and data are owned by whoever posted them (including attachments if any). The mailing list host is not responsible for them in any way.
