Migración de Datos

Migración de Datos

Durante 15 años nuestro objetivo ha sido el de darle un servicio integral a nuestros clientes, trabajar para conseguir sus propósitos y ofrecerles las mejores soluciones para el mercado de la distribución.
Han pasado ya más de 15 años desde que Datacenter Systems nació como empresa de servicios. A lo largo de esta andadura, hemos intentado poner todos nuestros conocimientos al servicio del mercado de la Distribución. En algunos casos, creemos que con herramientas e ideas novedosas, en otros a base de esfuerzo, dedicación y tesón, pero siempre teniendo claro cuál era nuestro objetivo, dar un servicio integral a nuestros clientes.

Durante estos años, juntos hemos vivido la evolución del mercado de la Distribución con las múltiples compras y recompras de enseñas de toda la vida por parte de grandes compañías multinacionales de Distribución o compañías de capital riesgo. Hemos vivido épocas de mejoría y juntos afrontamos peores tiempos, intentando adaptarnos a las necesidades de nuestros clientes en cada momento. En todos estos hitos, así como en el día a día, hemos intentado estar de vuestro lado y esperamos haberlo conseguido.

Datacenter Systems realiza la migración de datos y documentos, incluyendo “documentos vivos”.

La importación de datos no supone perjuicio alguno en el trabajo del cliente al no producirse paradas en las tareas diarias del cliente.
Existe todo un SISTEMA INTERMEDIO para la validación de la integridad de los datos migrados además de la opción de dar “valor por defecto” a datos que no existan en la aplicación anterior, pudiendo ser ignorados en algunos casos o con valores provisionales.
En este SISTEMA INTERMEDIO se puede aprovechar para depurar información antigua o innecesaria, con el fin de que el arranque se realice con la información más limpia posible.

Casos de Éxito:

Como éxito en Migraciones de Base de Datos tenemos por ejemplo la migración de la Base de datos de Mundo-PC que estaba en MySQL y utilizaban el sistema Ganso que es brasilero, la migración la realizamos 100% y cambiamos de su sistema Ganso al Datacenter en 24horas.

Otro caso de Éxito es el de Seven Tecnología cuya base de Datos estaba en Access y la migramos a PostgreSQL al 100% cambiando el sistema en 24horas.

La migración de Oracle 9i a PostgreSQL fue un completo sucesso con la Empresa Marisma S.A. para su sistema de control de Depósitos en el cual migramos mas de 150 mil productos.

Otro caso de mifración de Oracle 10g a PostgreSQL fue un completo sucesso con la Empresa Casa Lila Cosméticos para su sistema ERP con más de 10 mil productos y 1500 clientes.

También ofrecemos migraciones a micro empresas que utilizan Excel como fuente de información así como fué el caso de Comercial el Porvenir.

Tipos de Bases de Datos las cuales realizamos migraciones a nuestro Sistema

  • Oracle 9i
  • Oracle 10g
  • Oracle 10XE
  • Oracle 11g
  • Oracle 11XE
  • Oracle 12c
  • MySQL 4
  • MySQL 5
  • PostgreSQL 8
  • PostgreSQL 9
  • SQL Server 2000
  • SQL Server 2005
  • SQL Server 2008
  • SQL Server 2012
  • SQL Server 2016
  • Firebirb 1.5
  • Firebird 2.0
  • Firebird 2.5
  • Sybase
  • Interbase
  • Access MDB
  • DBF
  • Excel .xls
  • Excel .xlsx
  • CSV
  • TXT
  • XML
  • ODS
  • ODT
  • HTML
  • DOCX

Cuestionario cualitativo para evaluar la complejidad de la migración de una aplicación basada en Oracle

Básicamente el cuestionario pretende detectar posibles complicaciones en la migración. Según las contestaciones podemos inferir la complejidad de la BD y por ende posibles problemas de traducción. A continuación os mostramos las preguntas con posibles respuestas, indicando si deberíamos considerar las respuestas como preocupantes o no.

SIN ALARMA: en principio no plantea problemas frente a una migración ante la pregunta realizada
CON ALARMA: se ha de realizar un estudio en detalle antes de proceder al proceso de migración ya que se podrían detectar incompatibilidades.

  • ¿Cuál es el coste de la parada del servicio? ¿Cuánto cuesta una hora sin servicio la aplicación?
SIN ALARMA: Se trata de una aplicación usada en horario laboral de Lunes a Viernes..
CON ALARMA: Se trata de una aplicación usada 24×7 , las 24 horas del día los 7 días de la semana
  • ¿Cuántos objetos tiene la aplicación? ¿De que tipo? ¿Cual es su crecimiento esperado?
SIN ALARMA: Bajo número de objetos volumen y bajo crecimiento
CON ALARMA: Alto número de objetos volumen y/o alto crecimiento
  • ¿Se tratan datos sujetos a la LOPD? ¿De que nivel: Básico, Medio o Alto?
SIN ALARMA: No , Básico o Medio
CON ALARMA: Alto
  • ¿Cuáles son las características técnicas de la aplicación? ¿Es Cliente-Servidor? ¿Usa Citrix? ¿Qué ancho de banda necesita?
SIN ALARMA: Aplicación web que no requiere de plugins
CON ALARMA: Emuladores de Terminal antiguos , sistemas propietarios TSO,,…etc
  • ¿Justificaría la naturaleza de la aplicación crear más de un tablespace? (Por ejemplo : Un tablespace para DATOS y otro para INDICES, o un tablespace para los Objetos LOB…)
SIN ALARMA: Dos o tres tablespaces
CON ALARMA: Varios tablespaces con configuraciones especificas (READ ONLY, NOLOGGING,….)
  • ¿Se necesitan algún valor concreto en la parametrización de Oracle? (Por ejemplo: OPEN_CURSORS, JAVA_POOL_SIZE,…)
SIN ALARMA: Ninguno, o sólo parámetro opcionales
CON ALARMA: Uno o varios parámetros necesarios para el funcionamiento de la aplicación)
  • ¿Se necesita alguna opción de Oracle? (Por ejemplo: Opción de Intermedia, opción espacial,…)
SIN ALARMA: Ninguno
CON ALARMA: Se hace uso de alguna de las opciones de oracle las opciones oracle se licencian separadamente al gestor RDBMS, y solo pueden usarse en la “Enterprise edition” de Oracle La relación de las mismas eshttp://www.oracle.com/us/products/database/options/overview/index.html
  • ¿La aplicación puede ser totalmente funcional sin necesidad de otorgar los roles DBA y RESOURCE? ¿Qué privilegios mínimos son requeridos?
SIN ALARMA: La aplicación sólo posee privilegios sobre sus propios esquemas
CON ALARMA: La aplicación necesita privilegios de DBA , y/o privilegios sobre terceros esquemas
  • ¿Existe algún problema en usar como juego de caracteres en la base de datos UTF8 ?
SIN ALARMA: La aplicación usa un solo juego de caracteres(charset) y es de los habituales usados en España (UTF8, WE8ISO8859)
CON ALARMA: La aplicación usa varios charset y/o usa algún charset no habitual en España
  • ¿El esquema que almacena los objetos de la aplicación necesita algún tipo de mantenimiento Oracle? (Reconstrucción de índices, tipo de estadísticas,…)
SIN ALARMA: La aplicación necesita los mantenimientos habituales de una BBDD Oracle
CON ALARMA: La aplicación necesita mantenimientos adicionales a los habituales de una BBDD Oracle
  • ¿Puede separarse en una máquina independiente la Base de Datos Oracle de la máquina que aloja la aplicación?
SIN ALARMA: Si
CON ALARMA: NO
  • ¿La aplicación puede ejecutarse contra una base de datos Oracle en cualquier plataforma? (Windows, Linux, etc.)
SIN ALARMA: Si
CON ALARMA: NO
  • ¿Puede la aplicación usar los tablespaces temporales y los segmentos de rollback públicos que ya existan en la instancia, o es necesaria una gestión particular de dichos recursos? ¿Por qué?
SIN ALARMA: Si
CON ALARMA: NO
  • ¿Qué uso hace la aplicación de Oracle, principalmente es una OLTP o una DSS?
SIN ALARMA: OLTP
CON ALARMA: DSS