Subject Re: [firebird-support] Sizing conversion project
Author Reinier Olislagers
On 20-1-2012 23:23, Rick Debay wrote:
>
>
> We are using Firebird and I've been tasked with determining the costs
> for migrating to MS SQL Server. The last time I used the latter was ten
> years ago, and in the role of a Java programmer.
> Does anyone have any suggestions for how to come up with rough time and
> cost estimates?
>
> Also, I'd like pointers to FB vs. SQL Server comparisons, so I add those
> to the analysis. Obviously if the benefits don't exceed the costs of
> the migration, it won't make sense.
>
> Last, I'd like to exceed the requirements and throw in DB2 and Oracle.
> If we're forced to migrate, it doesn't make any sense to only consider
> one database.
>
Why not throw in PostgreSQL while you're at it?

I'm wondering about the reasons for the move: is it the number of
experienced Firebird developers, Db appeal/populularity, size
constraints etc?

From my (perhaps naive) point of view, going to DB2/Oracle/PostgreSQL
smacks of possibly moving "up" as far as processing power is concerned,
while moving to MS SQL Server smacks of going sideways or down...

Some perhaps obvious points:
- Knowledge gained through experience with Firebird will have to be
replaced with knowledge of new db, which takes time & money (includes
adapting for loss of FB functionality as Sean Leyne indicated)
- Migration effort also depends on the programming language involved and
support of that on the new db
- Depending on your users, they might be more likely to fiddle with an
MS SQL instance than a Firebird server, thereby breaking things. This
may or may not influence support costs.
- There is a MS SQL to Firebird migration guide that might give some
pointers for the reverse direction, while a bit dated.
- Migrating to MSSQL will tie you down to one server platform. Migrating
to one of the others will allow you to run the server on Windows and
various combinations of Linux/Unix. This can be a hidden cost in
flexibility.
- Firebird also provides for embedded deployment. For SQL Server you
would use SQL Server Embedded (or some such) which is not the same as
MSSQL Server (regular or Express Edition). You lose flexibility there, too.
- Obviously MSSQL server can cost you licensing depending on which
version you have to use for your product
- If migrating anyway, why not go for some ORM or database independent
driver solution (Hibernate, NHibernate, AnyDac) if the flexibility
improvements outweigh increased development complexity, added support
complexity and probable performance decrease

Sorry, I haven't been involved in migrations and don't know if there is
some formal method to perform these estimates. I'd be interested in
hearing about those.

Regards,
Reinier