Migrate base price, ean and delivery time

Hi Joerg Lindner,
We’d like to answer your questions below: 

Anyhow, these ‘Attributes’ are parts of the the ‘Default’ Attribut Set, together with a custom Attribute ‘ean’. How these contents can be migrate?
if the Attribut Sets, which are present in M1 must be generated manually in M2 or will the migration tool generate the Attributes and Attributsset in M2?

All custom attribute sets and attributes will be migrated by our migration tool. However, please note, custom attributes work properly if the 3rd-party extensions associated with such attribute sets are available for Magento 2.

Last but not least, whats about PayPal and Heidelpay (in general payment) migration of customer payment data (not setup)? Does this work?

We’re not entirely sure about this question. In general, all customers data, sales data and associated payment data will be migrated by our migration tool.
Meanwhile, you can check out a few case studies below to learn more about our UB Data Migration Pro version: 
-- We did use the Pro version ourself to help Winetasting.com – Migrate 382,047 customer entities to Magento 2
-- And this case study as well -- Freelaunch.nl used UB Data Migration Pro to migrate 230,000 products to Magento 2
-- Case Study: Successful Magento 2 Data Migration for Kwaaijongens.nl
Hope that helps.
PS. Please note our migration is available for Magento CE only.
Regards,
Ubertheme team

Hi Joerg Lindner, 
We’d like to clarify further below: 

but for the BasePrice there must be a Datamapping available as in M1 the attribute id’s/EAV are different than in M2, as the Base Price Module is made years ago (no longer supportet and developer no longer aktive).

For 3rd extension’s data, it would be safe to use if such 3rd party extension is ready for use in Magento 2. It’s beyond the scope of our migration tool to handle 3rd party extension’s data though.

The Base Price extension for Mr by Magenerds is pretty similar but has different attribute/EAV id’s!

Actually, our migration tool depends on Attribute code only, not EAV ids.
In general, our migration only focuses on core Magento database, as stated in our product page here. 
And many users have completed their projects successfully. A few to name: 
-- We did use the Pro version ourself to help Winetasting.com – Migrate 382,047 customer entities to Magento 2
-- And this case study as well -- Freelaunch.nl used UB Data Migration Pro to migrate 230,000 products to Magento 2
-- Case Study: Successful Magento 2 Data Migration for Kwaaijongens.nl
Regards,
Ubertheme team

Hi Jorg Lindner,
Please find our update below: 

• Migrate Product Attribute Sets, Product Attribute Groups, Product Attributes

So if you just migrate core default magento items, than you will not migrate any new Attribute as ean, delivery_time, base price attributes or other product attributes (incl. their content) as these are non standard attributes

We’d like to clarify further that our tool help to migrate the following attribute group and attribute sets:
-- System Attribute
-- Custom attribute
Custom attribute is optional which you can select to migrate or not (available via the migration dashboard)
For special custom attribute that requires 3rd party extension to work with (For instance: source_model, backend_model, attribute_model…), our tool still helps to migrate, however whether it will work or not depends on specific extension(s) that such attributes associate with.

Beside that, your description is stated in Step 9 to Migrate other Data. So this would be non core magento data, I expect. If you cannot make a data mapping for Step 9 how you like migrate other data or attributes?

Our latest Pro ver 3.x has revamped our migration dashboard and reduced to 8 steps. You can check out an overview of the new dashboard here. 
 

To migrate standatd core file, is easy and can be done with standard tools from Magento, so where is the difference?

We’re sorry for not being in the position to comment on Magento migration tool. You can give it a try. 
Anyway, from experienced with many completed projects (a few we shared in our previous reply), our users successfully ported all their M1 data to M2. 
Regards,
Ubertheme team

Hi Jorg Lindner,
Regarding your question via the email: 

— We are not talking about to generate the attributes used in Back end or in the source/code itself. These are already generated by the extension itself, just filling up the, relevant data, but the attribute id’s may be different.
For example the Baseprice:
M1 has a Extension from a developer no longer active. M2 = Magenerds. The Base Price Module in M1 use Attributes , base_price_amount, base_price_unit, base_price_base_amount and base_price_base_ unit to calculate the baseprice.
The Magenerds M2 extension use the attribute
baseprice_product_amount =(M1  base_price_amount)
baseprice_product_unit (=M1  base_price_unit)
baseprice_reference_amount (=M1  base_price_base_amount)
baseprice_reference_unit (= M1  base_price_base_unit)
So a data mapping would be needed to fill up the correct ‘attributes’ in the M2 target store.

We’d like to clarify that our current migration tool simply ports M1 attributes on as-is basis only. So any additional mapping between the custom attributes of your old (M1) Base Price Module to (M2) MageNerds will need a paid customization.
If you are fine with the custom work, we still need to confirm further on this point:
1. Your M2 Magenerds already generates its own custom attributes (baseprice_product_amount, baseprice_product_unit, baseprice_reference_amount, baseprice_reference_unit)?
2. Or our migration tool must create those attributes in M2 and map the value of M1 attributes into such M2 attributes.
PS. Please help to reply directly via this ticket, as we do not maintain technical support via email.
Regards,
Ubertheme team

Hi Joerg,
We’re off throughout the weekend, so our apology for the delay in responding to your additional question. We will follow up further with you when we’re back to our office next Monday. 
For now, please find our additional clarification below: 

Pls quote.

Please help to provide us a specific map of M1 attributes vs. M2 attributes, based on which we will let you know the estimated quote. 

As I understood correctly, the if i.e. a own attribute ‘ean’ is present at M1, a attribute ‘ean’ will be generated by your extension and the product data ‘ean’ will be migrate to this attribute.
What’s happening if the attribute ‘ean’ already exsist in M2? Will it be used?  

If the ‘ean’ attribute already exists in M2, we will keep using such attribute in M2. 

Last but not least, whats about PayPal and Heidelpay (in general payment) migration of customer payment data (not setup)? Does this work?

By default, our current migration tool only migrates customer payment data if those belongs to default Magento core table. If any customer data is stored in a custom table (for instance, the custom ‘paypal_payment_transaction’ table is not covered by our current tool). 
For Heidelpay, we’re sorry for not using it before, so could not give you confirmation for now. 
Anyway, custom payment data beyond the core Magento tables will need custom tweaks as per the attribute customization mentioned above. We will also need your help to understand about all such custom data tables, if you choose a paid customization option. 

This means that i.e. paypal transaction id, date , etc will be migrate to M2. Correct?

As explained above, all Paypal transaction data in the Magento core tables will be migrated to M2. Those in custom Magento tables will not be covered at present though.
Regards,
Ubertheme team

Hi J. Lindner,
We’re sorry for our late reply, as we’ve just been back from our weekend. 

paypal transaction information are stored in table’s  sales_flat_invoice(transaction_id), sales_payment_transaction (txn_id, parent_txn_id, txn_type) and sales_flat_order_payment (last_trans_id). I guess thes are core magento tables/fields.

All these are core Magento tables which are covered and migrated by our tool. 

even a part of Heidelpay transaction id will be migrate, correct?

If Heidelpay also stores their data in such core tables, such Heidelpay’s data will be migrated to M2 as well. 
In short, all data stored in custom tables beyond core tables as mentioned above is not handled by our migration tool at present. 
For instance, the custom ‘paypal_payment_transaction’ table is not covered by our current tool, as explained in our reply #8.
Regards,
Ubertheme team