We are setting up a new e-commerce site and while trying to figure out which platform to go with, I would like to know, is there way to migrate from MagentoGo to the Enterprise edition?
Cheers,
Iraklis
p.s. In case you want to contribute to our platform quest, feel free to write your thoughts on this post,
Both editions should have support. I would ask Magento what options you have.
Having said that, you can probably migrate most of the product information using the API and/or DataFlow. That will require you to write a script that takes the information out of Go and then put it into Enterprise Edition.
Orders will probably be a more complicated beast. There is an API available for orders so you will probably need to use that. However, migrating payment information may be tricky as you will likely charge the customer again. I would probably change the payment method to Purchase Order and put the PO value as "Migrated Order".
However, the first thing I would do is talk to Magento about what kind of options you have. I have to imagine that they have created a method for people to migrate out of Go and into Enterprise. They should be based some somewhat the same code so maybe the database can be moved over as well.
Related
We are migrating our store on Magento Go to community edition, due the former shutting down in Feb 2015.
The product import and basic customer customer info imported fine, but when customers try to login to their accounts magento tells them the password is incorrect.
Magento Go support explains this as different encryption algorithms used in go and community edition, but they also said it is possible to change the way password are decrypted/encrypted in magento ce?
Wonder if anyone has any thoughst on that?
p.s. we can ask all 1000s of customers to reset their passwords, but this wont look like a seemless migration for them.
There's an interesting guide over here regarding the downgrade from Enterprise Edition to Community Edition which addresses the different hashing mechanisms.
Downgrading Magento Enterprise to Community
Take a look at the file app/code/core/Enterprise/Pci/Model/Encryption.php . It contains the algorithm used by the enterprise version. So all you have to do is to create your own model and replicate the behavior. After that, tell Magento about the rewrite:
<helpers>
<core>
<encryption_model>Module_Namespace_Model_Encryption</encryption_model>
</core>
</helpers>
With that in place both frontend and backend login should work as before, no need to change passwords or anything.
You'll need to apply this for your instance of Magento GO instead of Enterprise, but the functionality in the end should essentially be the same.
Im looking at switching to Magento for a project im going to start.
I was wondering if i could get a bit of advice regarding the Multi-Store implementation.
Does this allow seperate admin users for each store?
Would you recommend this implementation for a small hosted ecommerce application?
Cheers,
Warning - as I'm sure you know, don't start a project with Magento unless you are willing to put a lot of time into it.
That said, to my knowledge the Multistore setup allows one to run multiple stores with the same administration section. You should be able to create multiple admin users - but restricting them to a store isn't available in normal old community edition. It might be available in one of the pay editions.
That said, this extension may do the trick for you: http://www.aitoc.com/en/magentomods_advanced_permissions.html. Note: I've never personally tried this extension and so cannot vouch for it.
Edit
I realized that I never answered your second question.
Though Magento is a very powerful platform with a lot of features, I would not recommend using it for a small hosted ecommerce application. For a small hosted ecommerce store I would consider running Wordpress with the WP-E-Commerce plugin. Wordpress is great for managing website content - and WP-E-Commerce has a lot of features and is consistently being developed and improved upon.
If you are going to go with Magento then I would reccomend using Nexcess hosting. They specialize in hosting Magento and their Magento plans are already optimized for running Magento websites.
enterprise (and maybe professional) edition has the feature you are talking about, separating admin users by store. If you need to restrict that in admin level with community edition you can set up multiple software versions from same development branch with different databases (git is awesome on version tool for that). Lots of different ways to do so if Enterprise is out of reach
regarding of performance i guess you will need a powerful VPS or dedicated machine if you are serious about it and as the traffic grows you then should think about load balancing. Look for magento dedicated host companies for that and it won't run in $5 or $20 per month hosts
You asked:
Does Magento allow seperate admin users
for each store?
The free version (Community version) of Magento doesn't have this feature. There will be a single admin.
But the admin can create user and roles. So, some users can be assigned only to product and category addition page. And some users can only be assigned to Sales part.
Separate admin for each store: This feature is present in Enterprise version of Magento but its cost is too high. At present, it Starts at $12,990 USD/yr
In my opinion, using or not using Magento depends upon the functionality you are searching for your shop.
If you need lots of features and functionalities for your Shop then go for Magento.
If you just want general functions like displaying product, adding to cart, and checkout (that's all), then you may search for any other open source shopping cart.
You may try Oscommerce. I have not used it much but I think there is a Oscommerce module for multi admin login for each store.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have some concerns about the Integration of Magento with other CRM,ERP systems.
How is it possible to integrate Magento with any other Industry standard CRM and ERP system?
How can i fetch the data from a ERP and update Magento database, like transactiona replication. Is this possible? And Whats the right way to do it?
Also, How can i integrate Magento with POS? Is it possible to have bi-directional data update between Magento and Industry Standard POS?
I hope I have stated all my doubts and made it clear. I would be thankful if someone guides me to do the integration, the Right way.
If you're using Magento Enterprise Edition, take a look at Bridge Connect, which is a service specifically built to integrate with common ERP packages. If you aren't using EE, or if you don't want to pay for Bridge Connect, your best bet is to use the webservices that Magento provides for this task.
The big advantage of using these is that they are relatively stable between upgrades, so you won't completely break your upgrade path. The downside is that they are slow. Silly slow. And they leak memory like a boat made of toilet paper. In my experience, though, this is nothing compared to the trouble of upgrading handwritten code when Magento decides to change the underlying database.
As for a POS, in simple cases the Magento admin sales interface may suffice. You can take CC payments, arrange shipments, etc, and your orders will be approximately the same as if they had been submitted from the web. If not, you're back to webservices if you want them in the Magento system.
If your ERP system is handling fulfillment, you may be able to skip the step of adding POS orders to Magento. Let the ERP system be the system of record for inventory, and just update Magento w/ the new accurate inventory quantities periodically.
Hope that helps.
Thanks,
Joe
EDIT:
Magento has not stated any plans to change the database that I am aware of, but it has happened several times in the past without warning, and it would be risky to assume that nothing will change. Varien does not make any guarantees about the database format, or whether it will be changed significantly.
When such a change happens, the APIs and objects in the platform are adjusted accordingly, so keeping it above the database level will keep you insulated from those changes, and make the job of evaluating new releases for compatibility that much easier.
The Magento orders/sales database structure was changed in latest release from EAV to flat structure (huge performance boost) and I don't foresee much changes in the near future, however it is highly discouraged to play with DB at the lowest level - try to integrate on Models level.
As for ERP integrations - there are couple options - BridgeConnect offers part of the functionality, webservices too (but there is no order creation in Magento via webservice for example) and you will need middleware or call API from 3rd party system. If you need speed, your best bet is to write a custom integration piece as a Magento extension. If you need flexibility and quick solution - use Webservice (you can extend them too with extensions).
As stated in your accepted answer your best bet is to use the API (either web service or XMLRPC). I used the API to build interfaces into and out of our ERP system using Mule ESB as the event/transfer layer.
If you can't find an API method you need and/or the methods don't work out for you, you can extend the API very easily.
Unfortunately, it looks like as August 2010 Magento does not support BridgeConnect any longer. There are some third party vendors who seem to filling the void for at least a couple ERM solutions.
Unfortunately, after much searching, I still haven't been able to find an integration solution for NetSuite.
Yes, API and XMLRPC/Web Services is the way to go. Another option is to look for pre-existing Magento Extensions that already do what you are looking for. The Bridge Connet is certainly an option and we considered it for our customers, however we ended up developing our own Magento POS Extension for RunIt POS.
The Magento Extension is now for sale on our website at https://www.activo.com/runway-magento-integration-with-runit-pos/ Check this link if you need more info, we also included an overview video and we have setup a demo for you to try if needed.
This is definitely a growing need as I see more and more web stores need to integrate with back end services due to the growing demand of online commerce. We will be rolling out new features and other extensions that enable online merchants do more with their existing Magento stores.
I think you should take a look on Quick Books POS integration with Magento also see ecc extension for sync srevice btw both systems.
Im interested in providing part of magento ecommerce as a SAAS solution. However, it would be great to get some clarity around the osl license.
I realise that distributing that actual software requires me to open the source. However, in a SAAS environment, surely I can charge for the software service? As long as I release all changes to the core code etc?
How about using the XML API to provide data - I guess thats ok too?
What about if I decide to let the user have the source code? what would I be obliged to do then? let them have it? release all changes?
Anyone have any experience with this? ps I realise you may not be a lawyer ;]
Cheers
Ke
What I would do is charge the user for the hosting. You can sell your customizations as you please as they technically are not subject to the Magento license.
I would stay away from making changes to the "core" code and instead build off of them. That way you are not selling modified versions of the core software (which would kill your ability to easily upgrade the system).
You are allowed to license your extensions however you please so you would not have to worry about the open source model.
The team I'm working with have created a CRM4 add-on which encapsulates 'standard' CRM customisations (such as modifying existing entities, adding our own custom entities), reports, plug-ins, and our own web pages (in IFrames) and web services. All pretty typical stuff.
I'm writing all the requisite installation code to simplify / automate the install process so that our ISV add-on can downloaded and trialled by anyone, but have been asked to think of appropriate way restrict functionality - to encourage people to purchase a license.
I'm not that familiar with the concepts/best practices/pitfalls when it comes to the 'licensing' of .net apps (especially CRM4 add-ons) so am asking you if you have any suggestions. We're looking for something fairly simple, and should be reasonably 'crackable', since we believe that having to enter a license code is generally a PITA.
Does the CRM API have anything to offer the ISV developer? (I see that one is able to nterrogate the License entity, but I'm assuming that this is for the CRM license itself)
Are there any existing code samples / projects / frameworks that are appropriate to use or implement?
I'm tempted to create a Registry Key upon installation of the add-on which, if after a month the correct license key has not been entered, will restrict functionality. Is this the best way to do this? Have you seen any other add-ons do it differently / better?
In terms of restricting functionality, I'm thinking of throwing InvalidPluginExecutionExceptions. Surely there must be a more 'graceful' way to do this?
All thoughts and suggestions appreciated.
Regards,
Peter.
My thoughts:
Yes, you can query the License entity to get the number of licensed users, which is a common license type from what I've seen. Lots of 3rd party vendors charge by the number of licensed users, regardless of how many of those users actually use the customization. I try to stay away from these because the license costs are often prohibitive for enterprise deployments.
Not that I know of.
I like this option, and have seen at least one 3rd party tool use this method. They allow you to declare the license key in your .config file, and if their runtime doesn't find it there it checks a known registry key. The tool comes with an app that registers the license key in the registry for you. I'd be careful to test and make sure your custom code can read the registry in a least-privilege environment.
Definitely not graceful to throw exceptions, but it does prove your point. :) Other than that, just outright skipping your code is another possibility, although that could have data implications. If you must throw exceptions, I would suggest trying to run some javascript on form load of your entities that warns the user that their license is expired and a save will result in an error. Some more nefarious schemes could include Thread.Sleep, kinda like the old shareware nagscreens. :)
Another idea - can you set up an Enterprise IFD deployment so you can give customers remote access to your demo, including their own demo organization? This depends on your audience, but your customers may not have the luxury (time, dev environment) of downloading and installing your trial. They may just want to see it in action - once you qualify the sale maybe you offer free remote installation and not spend so much time on a flawless setup package? Again, depends on your audience and the volume of licenses you expect to sell. Technically, you could dynamically provision organizations using the SDK and make the online trial process completely automatic. Of course this is a big investment, but allows you to maintain absolute control over your demo/IP.
Hope that helps!